This message is from the T13 list server.
Pat,
On your comment:
"Yes. Not transferring it back makes it indeterminate. If we're lucky,
the app zeroed its buffer before sending the command, so not
transferring back makes it zero."
No luck is involved at all. Since ALLOCATION LENGTH is always a maximum,
the host has to have some way of distinguishing how many actual bytes were
sent back. Counting them is probably best, although suitable use of flag
data could work (in this case it would since a flag byte of 0 would work
OK).
Note that the "last byte of data" is NOT indeterminate, since it was never
transferred nor expected (i.e. it just did not exists from the host's
perspective).
Jim
-----Original Message-----
From: Pat LaVarre [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 17, 2001 12:18 PM
To: [EMAIL PROTECTED]
Subject: [t13] fewer back is always ok? say again?
This message is from the T13 list server.
> "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/13/01 08:05PM
> assume that the device knows it is
> a 16 bit wide data bus ATAPI device,
Ok.
> so if it has an ALLOCATION LENGTH for return data
> it should only return 4 bytes (2 words).
Eh?
> Either way everything is legal and should work.
I got lost in the leap from "everything is legal" to "should work". Help me
out?
> The worse case is that if the host
> gives up at 4 bytes it does not get
> to see the additional INQUIRY return data.
Aye.
> You can always return fewer bytes
> than the ALLOCATION LENGTH,
> and this would be both legal for the device
Yes.
> and ... no possibility of 6 bytes getting to the host
> overflowing the ALLOCATION LENGTH size buffer).
Yes.
> For ... software .. the 5th byte ...
> is the number of additional bytes
> in the possible returned INQUIRY data.
Yes. Not transferring it back makes it indeterminate. If we're lucky, the
app zeroed its buffer before sending the command, so not transferring back
makes it zero.
> At this point the host software
> will either finish happy with its 4 bytes,
Eh? Not likely? The 8 bytes at offset 8 identify the vendor. The x10
bytes at offset x10 identify the product. Appearing to offer Inquiry data
that doesn't include these fields is likely to break hosts?
> At this point the host software
> will either finish happy with its 4 bytes,
> or will retry with a larger ALLOCATION LENGTH
Eh? How will the app know to do that? Remember, with Pio, this worked
fine. Ask for five, get the fifth, use the fifth to learn how many more to
ask.
Here we're saying apps, because of the potential to connect thru Atapi Dma,
should never trust the last byte of an odd byte count in, never trust the
last few bytes of any byte count out.
Ouch.
> retry with a larger ALLOCATION LENGTH
> (like it should have done initially).
Why should? Who when where how published this should?
> To return 6 bytes (three words) is
> to assume that the last byte falls away at some point
> - perhaps not an unreasonable practical assumption,
> but clearly violating the standard.
Yes. For example, this crashes Win95B. If you were asked for 5, Win95B
crashes, no matter if the device chooses to think 5 means 4 or 6.
> For example, if this was a wide (16 bit) SCSI device
> I could not get away with 3 words transferred
> unless I followed up with an IGNORE WIDE RESIDUE
> message (which does not exist for ATA/ATAPI).
Yes. AtapiPio offers an indirect equivalent: the device can make its last
x1F5:1F4 AtapiByteCount odd. AtapiDma offers no equivalent.
Pat LaVarre
Subscribe/Unsubscribe instructions can be found at www.t13.org.
Subscribe/Unsubscribe instructions can be found at www.t13.org.
