Fwd: why not H = C = D ModeSense6 for just the header
LAVARRE at iomega.com
Thu Feb 13 12:21:51 PST 2003
* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
> 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
> 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
What I don't understand is how Microsoft makes such
distinctions, since the two standards contain so much
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
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
> 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:
Thanks for talking, Pat LaVarre
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10