[t13] Re: Fwd: why not H = C = D ModeSense6 for just the header
Eschmann, Michael K
michael.k.eschmann at intel.com
Fri Feb 14 13:20:56 PST 2003
This message is from the T13 list server.
Interesting. Maybe taking a class from one of many "Windows" driver training folks would be useful to you? Walter Oney (oneysoft.com), OSR (osr.com) and and David Solomon (solsem.com) are some of the names that come to mind.
Here's my take on the whole ATAPI detection in a very abbreviated form:
In a Windows-based system, the storage stack has a low-level controller (host bus adapter) driver, that I'll call a port driver, that gets enumerated based on device ID (part of the whole PCI enumeration process) will know (by design) that it is controlling a SCSI, ATA/ATAPI, or whatever adapter. When an ATA adapter is found, it goes off and finds all devices attached to it's cable(s) and through an identification process determines if the devices are ATA or ATAPI. Now notice that the port driver is not directly communicated with, but rather sets up a bunch of entrypoint "device" nodes that tell higher-level drivers what kind of device is represented.
The higher-level drivers attach to these low-level device nodes, with some attach to nodes that are ATA HDD's, some attach to optical devices such as CD-ROM, DVD, etc., all based on what kind of node is presented. Note that this description is very abbreviated and contains errors that, for a 100k-ft view should be acceptable. So when a class/file driver pair access a device they basically know what it is, but not the specifics of SCSI vs. ATA/ATAPI.
So the file system has to assume SCSI since it doesn't have such information as what kind of command set it adheres to, and when a command is sent in through this device node entrypoint the port driver is then required to do whatever SCSI-to-whatever translation that is necessary. So if the driver screws this up, we know who's fault it is. This is not an ATA/ATAPI spec issue, but rather a OS stack design choice.
In my ever-shrinking mind, I see that many CD's will adhere to SFF-8020, and some (may I say "loosely"?) adhere to MMC3 and support both SCSI and ATAPI commands...to varying extents. This causes the port driver to thrash what it will send a drive, and a drive's support has to be determined on-the-fly. I don't like it, but it is reality.
Now for a pass-through mechanism the port driver still has to do translation, but what makes this more difficult is that there are no rules written down anywhere (either in protected or public space) that tell what is to be expected of the pass-through command, and some folks wish to pass in garbage and expect the port driver to always deal with it. This is where written-down covenants between high-level generator of pass-through commands and the port driver would be nice, but is somewhere in the space between reality and insanity.
Now how does a sender of SCSI-pass-through commands determine what the device-type is for the device they are about to pound on? You can send inquiry commands, or if you know a port-driver-specific IOCTL to get Identify-Device data you can do that. But you can't always just send any command that you choose. Lots of the low-level port interface in Windows is not published, so doing SCSI-pass-through is very much an acquired taste, of which many can't acquire.
Again: maybe you should try a Windows driver class, then you can hit them up with all this and see what they say. And for all you driver "experts" out there, I am just trying to convey the flavor of how Microsoft storage stack works, so don't get on my ass if I said something technically incorrect...I'm trying to write this quickly. Once I've written a letter and can no longer see the beginning I know that I've gone on way too long now.
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
> 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
More information about the T10