This message is from the T13 list server.
> I'll keep this brief I wish you well. > Some OS's at a high level treat everything storage > as "SCSI", so lower-level drivers must identify > their actual device and convert SCSI-2-Whatever. I've been told Windows works this way. The higher levels speak a Microsoft SCSI, which gets translated as needed as it reaches the device. > I believe this is the root-cause of your concern. I invented the plug 'n play descriptor code Usb bInterfaceSubClass x06 in order to plea for no helpful translation. As far as I know, that's what Microsoft then implemented there: pass thru Microsoft SCSI pure and unadulterated. Pure pass thru gives all power to the device to behave as expected or not. Incomplete and approximate translations work well only in the contexts they were designed to support, and when they break, the device can't help. > I don't know why Windows (shipped by Microsoft) > don't convert all the time, ...n't believe ... a > band-aid ... but rather a bridge of two different > standards (SCSI and ATAPI). I'm told that Microsoft translates if it concludes a device is "an ATAPI device" rather than "a SCSI device". What I don't understand is how Microsoft makes such distinctions, since the two standards contain so much in common. I've been told the distinguishing algorithm has been ad hoc and varied with time. I've been told, for example, that sometimes supporting mode page x02 Dis/reconnect classifies a device as "SCSI". I've been told some BIOS refuse to boot unless a device disclaims all ANSI compliance by zeroing byte 2 of the op x12 Inquiry data. I've been told that mode page x05 C:H:S existing matters too, though I'm not clear how. > ... What I also don't understand is why it ever made sense to create two competing standards, nor why Microsoft doesn't work harder to deny the reality of this mess. For example, Microsoft could send op x1A ModeSense6 and then only resort to op x5A ModeSense10 if the device in question replied SK ASC = x 5 20 Unsupported Op. But I suppose even trying op x1A would take Microsoft outside of the SFF standard and provoke who knows what response from an SFF device? > Microsoft) ... convert ... if a ... "widget" ... > cannot handle the 6-byte CDB for mode sense I can testify that Microsoft translates more often than that. > a 6 and 10-byte CDB differ As I imagine you know, the data differs too, in the size of the header and the size of header fields. > for proper operation use of the appropriate command > on the various devices Divining what Cdb is appropriate and what its bits mean is the whole issue. > OS pass-through mechanisms ... allow for innovation > that would otherwise be stifled. Personally I agree, but somehow I'm not able to state this argument in a way found compelling at: http://lists.apple.com/mhonarc/ata-scsi-dev/ Thanks for talking, Pat LaVarre
