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. MKE. -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 12:22 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] 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 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
