This message is from the T13 list server.
[ BC [EMAIL PROTECTED] ]
Caution: Unless my 4/14/02 8:02 AM answer to "[t13] on residue - short, concrete,
reproducible?" post made sense, this post might not make sense either ...
> Re: RE: [t13] SFF 8020i is dead?
>>> McGrath, Jim 04/13/02 21:06 PM >>>
> 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.
Yes I was not cracking the Scsi Cdb.
Cdb's have meaning in CONTEXT. Does x 08 0 0 0 01 0 Read One Block mean copy In x200
bytes or x800 or 0? Only context tells us.
> That should tell you something - the command layer protocol at either end were
>sorting things out just fine.
Yes the protocols at either end mostly work - but they don't just plain work.
Not cracking the Cdb worked reliably only when I was able to copy the same arbitrary
count of bytes that AtapiPio does. When I inadvertently rounded up the count, I broke
actual (revoltingly fragile) apps.
> ATAPIPIO, ... 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.
Yes.
> The only way you can know how many bytes should be transferred requires looking at
>the embedded SCSI command information ("cracking the CDB")
"Only way"? This depends on where we're looking.
Commonly the parameters passed to the Atapi host bus driver tell it not only the Cdb
we can see in a bus trace from a logic analyser, but also the max count of bytes to
copy which way.
Scsi-over-Usb (bInterfaceClass SubClass Protocol x 08 06 50) & Scsi-over-1394 (1394a
Sbp2 normative Annex B) politely pass the max count of bytes to copy which way over
the bus to the device.
T13 Atapi is less polite here, agreed.
> The only way you can know how many bytes should be transferred requires looking at
>the embedded SCSI command information ("cracking the CDB")
An AtapiPio device is in effect a cheap and widely available Cdb-decoder.
Given a Cdb, an AtapiPio device responds with a plain indication of the count of bytes
to copy which way. The BSY DRQ C/D I/O bits say if and which way to copy data. The
sum of x1F5:1F4 ByteCount says how many bytes to copy.
> 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.
Yes. I "should not" crack the Cdb when I bridge to AtapiDma.
> 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.
Yes some Scsi-over-whatever hosts & devices rudely round up transfer lengths.
> It is the fact that the host understands the command level nformation that allows it
>to parse the returned data (or the device to parse the date from the host).
Yes.
> 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.
Yes.
> 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.
Parallel eight-bit Scsi and AtapiPio and Scsi-over-Usb and Scsi-over-FireWire all let
the device ask to copy a precise count of bytes.
Atapi UDma stands alone in forcingthe device to ask to copy as many as X * 2 + 1
additional bytes.
Parallel sixteen-bit Scsi and Atapi Dma force the device to ask to copy as many as 1
additional bytes, hence the IgnoreWideResidue option, which I hear here was more
widely unused than even sixteen-bit Scsi was.
> progress
I think yes! Thank you again.
Pat LaVarre
>>> McGrath, Jim 04/13/02 21:06 PM >>>
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 ther 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
uderstand 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 nformation 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
