ATAPI is

Pat LaVarre LAVARRE at iomega.com
Fri Feb 14 08:38:37 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
> Re: Fwd: why not H = C = D ModeSense6 for just the header
> Pat, I don't understand your confusion

Thanks you for your interest, sorry I was unclear,
kind of everyone here to let me try again.

> 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.

I agree the very idea of distinguishing ATAPI from
SCSI bothers me.  What can ATAPI be except some
subset of SCSI passed over IDE.  But I can see
somehow in reality ATAPI has grown to be not quite
the same thing as SCSI, though lately SFF has been
changing to grow less pointlessly unlike SCSI.

Maybe seeing ATAPI only as SCSI over IDE indeed is
the Win NT/2K/XP algorithm?  Maybe there a device "is
ATAPI" only if Atapi.sys talks to it?

In Win 95/98/ME by contrast, I've heard we have an
"ATAPI bit" which drivers in the stack can set &
clear at will, according to such undocumented
heuristics as the choice of supported mode pages and
supported ops.

Untrue?

> Perhaps I am misunderstanding your scenario.

We have to answer completely & precisely both halves
of the whole question: when do we know a device is
ATAPI, when do we know a device is not ATAPI.

I'm told in Win ME/2K/XP, Windows/Inf/UsbStor.inf
limits generic Scsi over Usb to bInterfaceSubClass
in x 02 05 06.

Suppose a device reports not bInterfaceSubClass x06
"SCSI transparent command set" meaning Microsoft
SCSI, but instead bInterfaceSubClass x02 "SFF-8020i,
MMC-2 (ATAPI)" meaning PDT x05, or bInterfaceSubClass
x05 "SFF-8070i" meaning like a Compaq LS-120.

The way people have been speaking here, to follow SFF
rather than ANSI is to be ATAPI.  So maybe Windows
thinks of those devices as ATAPI also.

No?

I just checked recently.  Some of the more pernicious
binary incompatibilities remain, though they now
appear expressed as a binary incompatibility within
ANSI, e.g. mmc4r01f  "Table 447 – Mode Parameters
Header" vs. spc3r11 "Table 215 — Mode parameter
header(10)".

> Microsoft's ATAPI driver converts all Mode
> Sense(6)/Mode Select(6) command (including SCSI
> pass through ones)

Why all?  Anybody know?

> to Mode Sense(10)/Mode Select(10) commands for all
> ATAPI devices except tape devices (which follows
> the QIC157 streaming tape command set). 

Ah, fun.  This is to say, everything connected via
Atapi.sys is ATAPI, excluding only PDT x01?

> The KB article Q813908, sited earlier, is not
> relevant to this discussion.

Agreed.  I wish I knew better how to keep each titled
thread focused on its own subject, without then
discouraging informative free association.

> KB article Q813908 ... doesn't comment on a
> protocol problem

KB 813908 says that Win 2K thru SP3 applies an
astonishingly creative translation to ATAPI from
Microsoft SCSI.  If there were no conflict between
the T10 SCSI and SFF ATAPI standards, no translation
would be required, so the binary code only
translation couldn't astonish me.

> or the H=C=D behavior that was mentioned earlier. 

What's fun about KB 813908 is that it is a
counterexample to the oft-voiced theory that
H = C = D just plain works.

> > Win 95/98/ME

Last I checked Microsoft still supports Win back
thru Win 98SE or so.  Until Microsoft drops support,
we lesser players can't either.

> ...
 
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