This message is from the T13 list server.
Pat,
In parallel SCSI, at the transport layer, there is never any negotiation
over how many bytes to be transferred per command. Indeed, there is never
even a negotiation over how many bytes are transferred during any given data
phase. All of this is handled at the command level, not the transport
level. The same is true for SCSI transported over other physical
interconnects like Fibre Channel. The only thing the transport level does
is manage flow control (i.e. make sure that buffers do not dynamically
overrun) and error detection (e.g. CRC).
If your model is ATA as a transport for SCSI, and you want to make a
transparent transport level bridge, then you should be ignoring any
questions about the number of bytes transported per command. That is not
even comprehended by the transport layer. BTW, this includes ATAPIPIO,
which has no concept of the number of bytes transferred per command (it does
not appear as any of the ATAPI PACKET command status or command bytes. The
only way you can know how many bytes should be transferred requires looking
at the embedded SCSI command information ("cracking the CDB").
I expect that in practice you have not actually been looking at how many
bytes were transferred per command in your previous ATAPIO work, since you
were not cracking the SCSI CDB. That should tell you something - the
command layer protocol at either end were sorting things out just fine.
Note that you do need to transport things like the command status
information to the host from the device. It is information like that (and
the information embedded in the returned data that the host and device can
understand since they must understand command layer issues) that allows the
host and device to communicate with one another.
As a simple example, as was pointed out earlier by Hale, odd byte transfers
cannot physically happen on a PC - the hardware will not allow it. It is
the fact that the host understands the command level information that allows
it to parse the returned data (or the device to parse the date from the
host). A number of these rules may not be articulated in T13 and T10
standards, since they do not deal with host software interface standard
issues. That does not mean that no solutions exist however, since people
are clearly shipping product.
Bottom line: wanting to make ATA a transport for SCSI and worrying about the
number of bytes transferred per command is a contradiction. The only thing
ATA needs to do is to make sure that all the bytes generates by the
host/device are transferred to the device/host. Interpreting this
information is up to the command layer protocol. Afterall, this is exactly
how parallel SCSI works.
Jim
-----Original Message-----
From: Pat LaVarre [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 12, 2002 6:11 PM
To: [EMAIL PROTECTED]
Subject: RE: [t13] SFF 8020i is dead?
This message is from the T13 list server.
>>> McGrath, Jim 04/12/02 06:37PM >>>
Thanks for talking, thanks for listening.
> 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.
Yes.
> I think many would conclude that
ATAPI is not actually cleanly enough defined to allow transport only bridges
to operate successfully in all cases.
They'd be wrong about AtapiPio. Transport only bridges have shipped in the
tens of millions to Scsi from parallel printer port, AtapiPio, and Usb Mass.
They are ENTIRELY transparent.
> 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.
Here we lost me, sorry. I'd say ...
In Scsi, the command protocol at times specifies only the max count of bytes
to copy one way.
The actual count of bytes to copy results from a real time negotiation. If
the host and the device agree over which way to copy bytes, and the device
asks to copy less than or equal to what the host asks, then they both agree
to
copy the min of what they both asked.
The job of a Scsi transport protocol, therefore, is to resolve this
negotiation and copy the bytes. AtapiPio does this as well as eight-bit
parallel Scsi did.
How I think of Scsi appears in pictures at:
http://members.aol.com/plscsi/ftf.html#scsi
http://members.aol.com/plscsi/ftf.html#thirteen
> You appear to be contradicting yourself:
Sorry, I don't see my apparent contradiction.
I'm hearing T13 people tell me but of course always the host and the device
agree in advance over how many bytes to copy, else there is an error and
what
bytes get copied don't matter.
If T13 hasn't specified how the host and device do this, I don't see why we
should believe this claim. If a host can access a Pio register during Dma,
then why can't a host ask to copy more or less bytes in the same or
different
direction than the device does?
> 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.
But this isn't true in real life.
I agree this is one of the many fantasies published by T10.
But go and try it. It doesn't work.
x4402 Pat LaVarre [EMAIL PROTECTED]
http://members.aol.com/plscsi/
>>> McGrath, Jim 04/12/02 06:37PM >>>
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 ***
