> On Wednesday 14 September 2005 19:45, Timothy Thelin wrote: > > I was curious about the reasoning behind this decision and > how to fix an > > issue that came up because of it. > > ... > > (1) Is easy to do, but is it going to cause other issues? > I'd imagine any > > *usb storage* device that reports scsi0 really implements > the scsi3 form of > > the commands that it happens to support. > > (2) Is more invasive, but is probably more of a correct > solution. This > > will require a larger effort involving multiple groups > coordinating the > > efforts. > > I can't really comment on the rest of your mail, even though > the points seem > well thought-out, but I would like to offer just a single comment: > > Why would a usb-storage device ever report itself as scsi0 if > it actually > supports scsi3? Is it because the USB/ATA bridge spec doesn't > support asking > the device it self, so the usb-subsystem just makes an (un? > ;)-educated > guess? Or is it because it is possible, but the devices can't > be trusted to > tell the truth?
The reason they don't report scsi3 is because they don't claim to follow scsi3. They just *happen* to work with some cdbs that are formatted in a scsi way (probably scsi3 since these devices are newer). Since USB storage devices are getting made as cheaply as possible, they seem to do the minimal job necessary to support scsi commands; you can do your standard commands like inquiry, read, write, and some mode pages but they don't support the whole spec. So in consequence some (many?) of these devices say they support scsi spec 0. Which if you look at the scsi3 spec, 0 is a legitimate (not deprecated, reserved, or obsolete) value stating "I don't claim to follow any scsi spec" So the devices simply *happen* to work with the basic scsi commands. (Note: the above two paragraphs are my understanding of the issue after talking with people about these scsi0 devices that are appearing. It could be more complicated than the above, because each vendor has his reasons, but it doesn't stop the fact that these scsi0 devices exist) And so the issue is that the USB stack is auto-promoting these scsi0 devices to scsi2, and in turn the scsi stack adds LUN info to cdb[ 1 ] as per the scsi2 spec. So with the above in mind, here are the motivations behind those 2 solution proposals: Now since these devices were made recently with the scsi3 form of the spec in full-swing, I'd reason the form of the commands they *happen* to support are the scsi3 version since they need some sort of compatibility with the OS. This is the motivation behind the proposal to promote scsi0 USB storage devices to scsi3 devices. The question is are there scsi0 USB storage devices that don't support scsi3 commands enough? On the other hand, the more "correct" solution is to not promote at all and make the scsi stack aware of scsi0 devices. Basically this would mean the scsi stack would not auto-doing-anything since it does not know if the device needs it (i.e. adding in LUN info to cdb[ 1 ] ). This seems more "correct" of a solution, it's a lot more work and involves modifying both usb-storage and the scsi stack. Now granted the BEST solution would be for these USB storage devices to actually implement scsi3 like they should be doing, but they won't and so the software stacks need to take this into account somehow. Regards, Tim Thelin ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
