On Fri, Nov 04, 2005 at 02:49:55PM -0600, James Bottomley wrote: > On Fri, 2005-11-04 at 12:30 -0800, Matthew Dharm wrote: > > > What happens if you prevent USB mangling the scsi_level? I think, for > > > the most part, we would handle 0 in about the same way as we handle 2. > > > However, we could gate the if around the CDB[1] mangling as > > > > > > if (scsi_level != SCSI_UNKNOWN && scsi_level <= SCSI_2) > > > > > > which should fix your problem, I think. > > > > A long time ago, usb-storage didn't mangle the scsi_level. And almost > > nothing worked. Without a SCSI level, 6-byte commands get sent; only > > 10-byte commands will do. > > That area of the scsi subsystem has been changed significantly ... > mainly for usb storage. I don't believe your assertion about > SCSI_UNKOWN only producing 6 byte CDBs to be correct, the behaviour is > now governed by two scsi_device flags: use_10_for_rw and use_10_for_ms > which you can control in slave configure. > > Can you just try it with a modern kernel and see if anything still > breaks? I just realized this plan has a problem... The reported SCSI level of a device is mostly garbage, but not always. I've seen 0, 1, 2, 3, and 0xff all reported. HOWEVER, the reported value seems independent of what devices have vendor-specific commands (and thus need the CDB[1] not messed with). It is an interesting experiment to remove the force-to-SCSI_2 part of the usb-storage code (on the general principal of "we shouldn't be messing with the data passed through the driver), but it doesn't solve the original question of needing a way to pass commands without CDB[1] getting altered. Matt -- Matthew Dharm Home: mdharm-usb@xxxxxxxxxxxxxxxxxx Maintainer, Linux USB Mass Storage Driver Pitr! That's brilliant! Funded by Microsoft refunds. What sweet irony! -- A.J. User Friendly, 2/15/1999
Attachment:
pgp6YJFGKIyqm.pgp
Description: PGP signature
