[t13] Re: Fwd: why not H = C = D ModeSense6 for just the header

Nathan Obr natobr at windows.microsoft.com
Thu Feb 13 17:28:55 PST 2003

* From the T10 Reflector (t10 at t10.org), posted by:
* "Nathan Obr" <natobr at windows.microsoft.com>
Pat, I don't understand your confusion about determining if a device is
an ATAPI or SCSI device.  If a device is on an ATA bus and responds to
Identify Packet Device then we know it is ATAPI.  Perhaps I am
misunderstanding your scenario.

Microsoft's ATAPI driver converts all Mode Sense(6)/Mode Select(6)
command (including SCSI pass through ones) to Mode Sense(10)/Mode
Select(10) commands for all ATAPI devices except tape devices (which
follows the QIC157 streaming tape command set).  

The KB article Q813908, sited earlier, is not relevant to this
discussion. It doesn't comment on a protocol problem or the H=C=D
behavior that was mentioned earlier.  


-----Original Message-----
From: Pat LaVarre [mailto:LAVARRE at iomega.com] 
Sent: Thursday, February 13, 2003 12:22 PM
To: forum at t13.org; t10 at t10.org
Subject: [t13] Re: Fwd: why not H = C = D ModeSense6 for just the header

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

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:

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 mailing list