> > How about we blacklist all the bInterfaceSubClass that Windows does not
> > regard as generic. I remember Windows does regard bInterfaceSubClass =
> > x06 as generic. I think I remember there are two others.
>
> grep -i generic
> in windows/inf/usbstor.inf yields, hex:
>
> 08 02 50
> 08 05 50
> 08 06 50
>
> How about we [guess] disk writable
> [without risking mode sense]
> if we do not find bInterfaceSubClass in
> the set x 02 05 06?
In short:
Or how about we only blacklist mode sense from devices that report
bInterfaceSubClass = any of the x07..FF Reserved codes? Surely a device
sending us a formally Reserved code is a good first clue that it may not
behave robustly thereafter? Or maybe we just blacklist mode sense from
bInterfaceSubClass = xFF FormallyReservedButInformallyVendorSpecific?
Surely a device sending us that code is an even better first clue that
it may not behave robustly thereafter?
At length ...
usb.org --> Developers --> Documents --> USB Device Class Specifications
--> Approved yields:
http://www.usb.org/developers/devclass_docs#approved
http://www.usb.org/developers/devclass_docs/usb_msc_overview_1.2.pdf
xpdf then shows, in page 6 of 7, "Table 2.1 - SubClass Codes Mapped to
Command Block Specifications"
x01..x06 = RBC SFF-CD/MMC QIC UFI SFF-FDD SCSI
x07..xFF = "Reserved for future use."
De facto practice says xFF = vendor-specific, by analogy with other
usb.org texts.
Blacklisting mode sense from all but 02 05 06, same as Windows, means
blacklisting all but QIC SFF-FDD SCSI. Maybe uncomfortably aggressive.
> > Here we have bInterfaceSubClass = xFF ...
> > > That's this device TELLING US THIS DEVICE DOES NOT TALK SCSI.
By the way, kudos to Dmitri Katchalov for including USB descriptors in
the trace, rather than tracing only CDB's & data.
Pat LaVarre
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
