On Mon, 6 Jan 2003, Doug Ledford wrote: > On Mon, Jan 06, 2003 at 04:46:47PM -0800, Matthew Dharm wrote: > > On Mon, Jan 06, 2003 at 05:23:22PM -0500, Doug Ledford wrote: > > > Except that if a device *does* transfer 36 bytes and then lies and says it > > > only transferred 5 then we are missing information that might actually be > > > usefull, hence the reason to set the transfer length up to the real amount > > > transferred (and BTW, I would only do this for INQUIRY responses, for > > > anything else the device is simply too buggy to live if it lies about the > > > transfer length). > > > > First, I think this is a bogus situation. If we reqest 36, get X, and > > indicate a total of 5, then we should look at the X we got. And that has > > to be indicated by resid. > > I disagree. For a compliant SCSI device, it's legal for it to return all > 36 bytes of data, but only have the first 5 contain anything and the rest > all be NULL pad bytes and to put 0 into the extra data field. We are > *suppossed* to be able to rely upon that extra data field being reliable. > Just because sbp2 and usb scsi device manufacturers are such half-wit > shops that they hire entry level java programmers that couldn't write to a > standard to save their mother's lives doesn't mean that we should be > wrecking the scsi standards at the core level to compensate.
Hmm. Sounds like Doug is trying to have it both ways. He wants to be able to handle the case of a device that transfers 36 bytes but only indicates 5, where the remaining 31 bytes are valid and contain useful information (a broken device). He also wants to handle the case of a device that transfers 36 bytes and only indicates 5, where the remaining 31 bytes only contain padding (legal according to the SCSI spec). It seems clear that the driver doesn't have enough information to distinguish these cases by itself. How about this as a compromise? Have the fix_inquiry_data() routine in storage/protocol.c adjust the additional-length byte if it indicates less data than actually got transferred (and maybe also < 36 bytes), _unless_ an unusual_devs.h flag bit is set (something like US_FL_DONT_FIX_INQUIRY_LENGTH). This flag would only be needed for devices that transmit useless padding, and presumably these are much rarer than the brain-dead devices that have an invalid additional-length byte. In fact, maybe there aren't any examples of any such USB storage devices, in which case the flag would be unnecessary. Alan Stern ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
