This message is from the T13 list server.
> Interesting.
Thanks for saying.
> Note that this description is very abbreviated and
> contains errors that, for a 100k-ft view should be
> acceptable.
Indeed, what you say fits what I heard before, I see
no errors, so if I'm wrong here, the 100k-ft view is
what is misleading me.
I'm tainted with obscure bits of knowledge, like the
idea that the first Cdb's seen in Windows life come
from something low level trying to differentiate,
for example, CD from DVD. I'm told that's why the
first Cdb's can differ by bus type, not just by PDT.
> 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 ... the port driver ...
> required to do whatever SCSI-to-whatever
> translation ...
Mmmm, I wonder if here we agree.
Yes, the port driver has to speak Microsoft SCSI.
Yes the port driver could translate Microsoft SCSI to
something else.
But some of the port drivers pass Microsoft SCSI thru
to a device that supports Microsoft SCSI, rather than
translating. That works too.
And already some of the port drivers answer Cdb's
without passing anything thru. Microsoft could add
a vendor-specific Cdb to Microsoft SCSI to
distinguish SFF vs. ANSI, and just never pass that
Cdb thru to any device.
> This is not an ATA/ATAPI spec issue, but rather a
> OS stack design choice.
I think currently this issue is falling into the void
between T10 and T13. T13 wisely left the ATAPI Cdb's
out of its ATA/ATAPI specs, but then stopped short.
T13 hasn't taken the natural next step. Since T13
doesn't say what the Cdb's are, T13 can't say the
device and the host have agreed in advance out of
band how many bytes to copy which way for any given
Cdb.
T13 can say T10 should fix this, but that hasn't gone
anywhere, for at least a decade now, so by now it's
silly to pretend it ever will.
T10 does now own our Cdb mess more clearly than ever.
Starting with MMC-4, we see MMC admit that Inquiry,
Mode Sense, etc. of T10 MMC is not the same as the
like-named commands of T10 SPC, whoops.
> many CD's ... SFF-8020 ... MMC3 ... both SCSI and
> ATAPI commands ... varying .... I don't like it,
> but it is reality.
I like talking about reality, thank you.
> Now for a pass-through mechanism the port driver
> still has to do translation,
Lost me, help? If an app is talking pass through to
a device, how does it help to pass through anything
but what the app sent?
> there are no rules written down anywhere ...
> written ... nice ... between reality and insanity.
Yep. In the absence of rules, host & device vendors
differentiate themselves by how well they cope with
the unexpected. I mean to be suggesting we (T10 & T13) admit
that unpleasant reality, and begin to codify (T13) how to
cope with some of the unexpected that most commonly
occurs.
> 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.
Yep.
> Maybe ... a class ...
I wonder if my perspective would change. My sense of
the meaning of Windows PDO, FDO, bus driver, port
driver, etc. all comes second-hand, from working with
lots of folk who write Windows drivers, after having
taken those classes you mention. I'm told the DDK
in particular is incorrect, if read literally.
Thanks for talking, Pat LaVarre
-----Original Message-----
From: Eschmann, Michael K [mailto:[EMAIL PROTECTED]]
Sent: Fri 2/14/2003 2:20 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc:
Subject: RE: [t13] Re: Fwd: why not H = C = D ModeSense6 for just the header
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.
