This message is from the T13 list server.
> [EMAIL PROTECTED] 12/10/01 21:37 PM I feel like I'm now repeating myself, but maybe in the context of the other new discussion my remarks here will make more sense now. > > You only have one step further to go: > > all you have to add is your explanation > > of HOW the host and the [device] > > come to agree over how many bytes > > they jointly agreed to move. > For an ATA command > the command code and other command parameters > (such as the Sector Count) > exactly specify the number of [blocks] > that will be transferred if there is no error. Ata? Yes. > For an ATAPI PACKET command > the "SCSI CDB" specifies > the number of bytes > that will be transferred if there is no error. I think we're connecting. I'm saying exactly this is only true enough to be misleading. Consider the short concrete example of a common cb like x 12 0 0 0 FF 0. Ansi says this is an Inquiry for up to xFF bytes. How many bytes is that? However many the device likes. Almost never xFF. Gag, blech, ouch. A byte count not agreed in advance, built into the protocol, thank you Ansi Scsi folk. There is no ERR here when the device cuts the host short. The host should not respond with op x03 RequestSense merely because the device cut the host short. There is here in Atapi only an abomination we have most carefully excluded from Ata: the idea of an unexpected data transfer length that is not an error. > the command and the command parameters > told both that value. No mass storage standard I know of tries to make the command block say more than the _max_ permitted transfer length in the only permitted direction. By definition, the host and the device cannot agree in advance whether the device will try to cut the data transfer short, unless a standard forbids that possibility altogethe. The indeterminacy in Atapi Dma gets us into trouble whenever the host and the device disagree over what the _actual_ byte count should be: whether they agree or not over the max _permitted_ byte is not material. > which way ... move data (if ... move data) > and how much data ... > ... without violating the ATA/ATAPI command protocols. The word choice here bothers me. Last I checked, T13 publishes no protocol that decides the direction and max permitted byte count of any Atapi command block. To argue that an Atapi device is violating some other Atapi protocol, we first have to argue out which other Atapi protocol applies, which turns out to be a painfully fuzzy question. > the command and the command parameters > told both that value. There is no guessing here. I think we're connecting. I'm saying exactly this is commonly not true. I'm saying there's Lots of guessing here, because Usb bus traces make it easy to see it go wrong and there so often I do see it go wrong. The command block told the host and the bridge and the device the same thing only if the meaning of the command block was well-standardised before the first of these shipped. I buy fully transparent bridges in part because they competently transport all the vendor-specific commands we use in manufacturing. What kinds of field commands are well-standardised? Not much beyond block read/write of x200 (512) byte blocks from non-removable media with vanishingly low error rates. I hear tell of devices that even get Inquiry wrong: they choke over anything but the de facto Wintel standard of x 12 0 0 0 24 0. > There is no explanation > for "HOW the host and the [device] > come to agree over how many bytes > they jointly agreed to move". Agreed. There is no explanation because this is an open loop process. The host & device agree what the byte count should be when you're lucky, no more often than that. With AtapiPio, life is a little better: the host can observe precisely what the device thinks thebyte count is and then choose how to reconcile any differences. If you care about plug 'n play beyond Windows, you'll learn to cope when the byte counts don't agree. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
