This message is from the T13 list server.
Pat,
You appear to be contradicting yourself:
>> T13 doesn't describe the SCSI command set for any ATAPI device.
> This reality doesn't make a T13 claim that T13 specifies how the host
and the
> device come to agreement over how many bytes to copy which way too
very
> credible, does it?
I don't think anyone ever claimed that any T13 document described how many
bytes to transfer for a ATAPI PACKET command. That's the whole point. If
ATAPI was a transport protocol, then it has no business defining how many
bytes are transferred for the command that it is transporting. A transport
protocol just concentrates on how many bytes to transfer per block and/or
DMA burst. It is up to the command protocol to specify how many bytes
should be transported for the command.
In ATAPI PACKET command, that command information comes from the "embedded"
SCSI (actually MMC set) commands transported via the PACKET command. And
that in turn is defined by SAM and the SCSI command sets - all matters for
T10, not T13.
With the exception of the odd byte issue and the (documented) provision for
devices to accommodate hosts that overrun data transfers because no one
bothered to program the host adaptor hardware correctly, all of you
questions are as applicable for SCSI as they are for ATAPI - they are issues
dealt with by T10, not T13. And since you have to understand these SCSI
commands in order to "know" how many bytes should be transferred, the
strictly T13 issues are irrelevant. That is, you always know when a pad
byte is a pad byte, and you always know when a host overran sending data -
since your baseline information is from the SCSI command you transported,
and that will always give you the information you need to sort things out.
Indeed, ATAPI actually relies on this in order to make itself work.
If you want to make a transport only bridge, you have to ignore questions
like "how many bytes should be transported in a command" - all the other
transports I know of behave in that manner. It is a question for the
command level aware endpoints, not the bridges. If you cannot do that, then
the complete set of protocols are not layered well enough to allow a
transport only bridge - so don't do one. I think many would conclude that
ATAPI is not actually cleanly enough defined to allow transport only bridges
to operate successfully in all cases.
Note that historically the originators of ATAPI never intended for it to be
a transport for SCSI commands. And indeed, it was first implemented in
hosts in the ATAPI.SYS driver, which in turn is not a layered driver. A
number of these issues only become visible only you start implementing ATAPI
device support through layered protocol stacks.
I don't know if ATAPI should evolve to become a more transport protocol for
SCSI commands. What I do know is that is not how it works today - it is a
strange hybrid. And changing that will require work in T13, T10, and by
implementers (both device and host). And it will take years. It is not a
trivial project.
Jim
-----Original Message-----
From: Pat LaVarre [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 12, 2002 4:51 PM
To: [EMAIL PROTECTED]
Subject: Re: [t13] SFF 8020i is dead?
This message is from the T13 list server.
> > I'd love to hear people evaluate this claim. Does anyone on
> > Earth know of Atapi devices that don't put a zero there?
...
> Don't know... Good question.
One other thought: last I checked (1999?) Microsoft WHQL required SFF, not
Ansi.
> > Offline I've seen the claim that nearly all actual Atapi
> > devices, if intepreted per Ansi,
> > TELL the host to use SFF rather than Ansi. Specifically, this
> You mean interpreted per T10 MMC-x, correct?
Yes Ansi T10 http://www.t10.org/scsi-3.htm
ftp://ftp.t10.org/t10/drafts/s2/s2-r10l.pdf
Or ftp://ftp.t10.org/t10/drafts/spc2/spc2r20.pdf
Or ....
On this issue of what a zero means at offset 2 of the data copied by op x12
Inquiry, AFAIK, all the T10 publications agree.
> T13 doesn't describe the SCSI command set for any ATAPI device.
This reality doesn't make a T13 claim that T13 specifies how the host and
the
device come to agreement over how many bytes to copy which way too very
credible, does it?
> T13 only defines the ATA/ATAPI physical
> transport and PACKET command protocol.
Except T13 left out from AtapiDma the feature of letting the device ask to
copy arbitrary counts of bytes that AtapiPio offered.
x4402 Pat LaVarre [EMAIL PROTECTED]
http://members.aol.com/plscsi/
>>> Hale Landis 04/12/02 10:52AM >>>
This message is from the T13 list server.
On Fri, 12 Apr 2002 07:46:25 -0600, Pat LaVarre wrote:
>This message is from the T13 list server.
>Offline I've seen the claim that nearly all actual Atapi
>devices, if intepreted per Ansi,
You mean interpreted per T10 MMC-x, correct? Because T13 doesn't
describe the SCSI command set for any ATAPI device.
>TELL the host to use SFF rather than Ansi. Specifically, this
>claim says that ... In response to the standard, start of life,
>plug 'n play query of `plscsi -v -x 12 0 0 0 24 0 -i x24`, most
>actual Atapi devices copy in x00 as the byte at offset 2.
OK. So this is what a certain SCSI subset, the subset we call
ATAPI, should do for this command? If T10 does not recognize
this subset then what does that mean?
>Ansi T13 had no comment on what this means, last I checked.
Again T13 doesn't have anything to do with SCSI command sets.
For SCSI devices using the ATA/ATAPI interface as the SCSI
physical transport layer, T13 only defines the ATA/ATAPI physical
transport and PACKET command protocol.
>Ansi T10 says this is an op x12 Inquiry of up to x24 bytes.
>(That's close to real - it should copy in x24 bytes always.)
>Ansi T10 says x00 at offset 2 means the device "may or may not"
>comply with any particular Ansi standard.
OK. Sounds like a prefectly valid thing for T10 to say.
>SFF says SFF-compliant devices shall put a x00 there.
OK. I'm sure that is because SFF-8020 was an attempt by a few
individuals to redefine SCSI to their way of thinking. I think
we can safely say these people failed, SFF-8020 is now very
obsolete. ATAPI device should be implemented according to the
appropriate SCSI command set documents, such as MMC-x. That
means such device would not be putting 0x00 in this Inquiry data
byte.
>I'd love to hear people evaluate this claim. Does anyone on
>Earth know of Atapi devices that don't put a zero there?
Don't know... Good question.
*** Hale Landis *** www.ata-atapi.com ***
