On Mon, Nov 22, 2010 at 02:02:06PM -0500, Douglas Gilbert wrote: > On 10-11-22 12:07 PM, Linus Torvalds wrote: > >On Mon, Nov 22, 2010 at 8:56 AM, Luben Tuikov<ltuikov@xxxxxxxxx> wrote: > >> > >>Some kernel transport drivers unconditionally disable > >>retrieval of the Caching mode page. One such for example is > >>the BBB/CBI transport over USB. > > > >One reason for that is that historically we've seen devices that > >simply go crazy - to the point of simply stopping to respond to > >anything - when you ask for pages that Windows doesn't ask for. > > > >It's especially common on USB storage, but it happens elsewhere too. > >The device firmware simply hasn't ever been tested in that situation, > >and it's buggy. > > > >So I don't mind the patch per se, but I think it's potentially way > >more dangerous than it looks. > > The vast majority of USB mass storage devices are based > on SCSI-2 (1994) or a particularly nasty standard > called RBC (Reduced Block Commands, 1999) which is a > partial subset of the block commands (i.e. disk related). > We are all aware of the quality of most of the device > end implementations out in the wild. Not true. The vast majority of USB mass storage devices adhere to no SCSI or T10 specification at all. The official definition of the "Transparent SCSI" operating mode of the USB Mass Storage Class is "that which microsoft/sun/other major vendors use". Of course, that's not written down anywhere, but it was the intent of the committee and that is the reason why the committee rejected all attempts by people like me to implement a command-based compliance test. > I believe what Luben is working with is a new standard > called UAS (soon to be ratified) which is based on > www.t10.org work in the last few years. It seems to be > an attempt to throw out the older USB mass storage > transport and do it again, properly. Luben's patch changes the behavior of sd-mod, which would affect both usb-storage and UAS. The primary thing that UAS adds is support for USB 3.0 streams and TCQ, which are both designed to improve performance. I consider it likely that the quality of device firmware will be equally poor as older devices. That said, Luben's patch is kinda slick. sd-mod already asks for a lot of mode page data; it does this so that it's request matches the observed behavior of a "popular" Redmond, WA-based OS. Luben's patch just searches through that data to see if it can find what it is looking for, rather than rqeuesting a specific mode page later (which may not be supported). That said, I still consider this somewhat risky. We've seen devices with grossly inaccurate data before. But, to my thinking, as long as the devices don't see any change in the command stream, then I think the risk has been properly mitigated. To my understanding, this is the case. Matt -- Matthew Dharm Home: mdharm-usb@xxxxxxxxxxxxxxxxxx Maintainer, Linux USB Mass Storage Driver Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed suction darts! -- Salesperson to Greg User Friendly, 12/30/1997
Attachment:
pgpBOjHkTrAFu.pgp
Description: PGP signature
