[7196] in linux-scsi channel archive
Re: Fixing SCSI Layer
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Thu Sep 9 15:03:54 1999
Date: Thu, 9 Sep 1999 21:20:56 +0200 (MET DST)
From: Gerard Roudier <groudier@club-internet.fr>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
cc: mark@iphase.com, linux-scsi@vger.rutgers.edu
In-Reply-To: <E11OpVt-0002lm-00@the-village.bc.nu>
On Wed, 8 Sep 1999, Alan Cox wrote:
> > This flaw in Linux-SCSI requires driver to be able to handle any transfer
> > direction required by a device for a command. Usually, the direction is
> > enforced only for common opcodes as READ*/WRITE* and friends. For non
> > usual commands the driver/controller pair must wait the first data phase
> > asked by the device to know about the transfer direction.
>
> Many drivers cant wait for the phase to decide. They have to use tables or
> be told
Indeed, and we should, at least, provide direction for SCSI commands asked
by peripheral drivers that are kernel modules.
I suggest the following to be done ASAP:
1 - Add a 'direction' field to the scsi command structure that can be
filled with the following values:
DIR_INPUT, DIR_OUTPUT, DIR_NONE and DIR_UNKNOWN=0
Set this field to DIR_UNKNOWN=0 by default.
2 - Make kernel modules that request SCSI IOs (basically sd.c, sr.c, ...)
provide the right value for the transfer direction.
(1) does &llow SCSI driver maintainers to prepare changes, but still
handling the case of the direction being unknown.
(2) does make things correct for all IOs asked by the kernel.
I suggest you to include (1) + (2) in your current SCSI cleanups.
For applications, we must find some way for the direction to be passed to
the kernel without breaking compatibility.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
