Eric Youngdale wrote:
>
> Yes, this is a known limitation of the generics interface. Perhaps Doug
> has further comments. I am wondering whether we need some sort of table
> (not unlike what you already have) to set the data direction in the generics
> interface if it isn't specified by the user. The major bugaboo is going to
> be vendor specific commands, as tables are not going to be of much
> assistance here.
>
> -Eric
>
> ----- Original Message -----
> From: "Matthew Dharm" <[EMAIL PROTECTED]>
> To: "The Linux SCSI list" <[EMAIL PROTECTED]>
> Sent: Tuesday, April 18, 2000 8:14 PM
> Subject: sc_data_direction -- will we require it?
>
> > Well, I'm working on polishing up my virtual HBA for usb storage devices,
> > and I realized that it would be really nice to rely on the
> > sc_data_direction field to tell me which way the data transfer is going to
> > go.
> >
> > For reference, I _have_ to get this information from somewhere. I have to
> > know ahead of time which way the data will flow to set up the USB
> > transaction properly.
> >
> > Right now, I have my own little table of directions. Unfortunately, it
> > could be wrong in some places -- I can't really test it very well. So I
> > thought I'd just shift to using the sc_data_direction field.
> >
> > Unfortunately, most applications don't set this bit yet. Any request
> > which originates from within the kernel will have it set correctly.
> > However, requests from userspace applications (such as cdparanoia) will
> > not have it set.
> >
> > So, my choices are either to (a) stick with the unreliable but apparently
> > functional table, or (b) use the field and be prepared to reject commands
> > which don't have the field set.
> >
> > But, as I was thinking about it, it occured to me that the only way we
> > would get people to being using this field in a widespread way would be to
> > make the SCSI layers enforce this -- that is, reject any commands issued
> > that didn't indicate the direction somehow.
> >
> > Are there any plans to do this? Or are we going to continue to support
> > old applications on 2.4.0 which don't set this field? I realize that
> > there may be lots of applications which need updating, but it's a pretty
> > simple update to make and it does coincide nicely with a pretty big kernel
> > release (which is a time when developers should be going back to make sure
> > that their programs work with the new interface).
The sg driver is between a rock and a hard place on this one.
The sym/ncr53cxx drivers do nasty things on the PCI bus if the
data_direction flag is wrong (crash??) but it will safely cope
with SCSI_DATA_UNKNOWN. This was discussed in a linux-kernel thread
titled: "2.3.00p1/2.3.49: more problems concerning devfs & generic
scsi" [started 17th March 2000]. So sg was changed and now
(2.3.99-pre5) the logic is:
if (sg_header_interface)
send SCSI_DATA_UNKNOWN is _all_ cases
else if (sg_io_hdr_interface)
send through direction flag indicated by user
All existing applications use the sg_header interface so USB will
have problems as you have indicated. The danger with the sg_io_hdr
interface is that the app gets the direction flag wrong and the
above-mentioned drivers bring down the kernel.
Cdparanoia has the nasty habit of setting the buffer counts on
sg_header to indicate data is both being written (i.e. transfer
user data into the kernel buffers) and also read (i.e. transfer
user data from the kernel buffers). [It does this "trick" so
that on a read-like opcode it can detect a short read (with luck).]
So with a vendor specific opcode and buffer counts indicating
a bidirectional transfer, sg has no way of knowing the true
data direction. [In defence of Monty (cdparanoia's author)
I know he is keen to switch to the sg_io_hdr interface as
soon as 2.4 becomes available.]
Now sg does know which HBA driver it is talking to and can
change its direction reporting policy on that basis. That
seems likely an ugly development to me. Also most anything
that can be done with sg can also be done through the
SCSI_IOCTL_SEND_COMMAND and CDROM_SEND_PACKET ioctl()s.
IMHO HBA drivers should react in a passive fashion when given
an incorrect direction flag. If not then the pass through
mechanisms have little option other than to send through
the SCSI_DATA_UNKNOWN flag. Even when HBA drivers act benignly,
if the pass through interfaces guess the data direction
incorrectly (rather than pass through "UNKNOWN" in difficult
cases) then a previously working app may be broken.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
