This message is from the T13 list server.
> <[EMAIL PROTECTED]> Helpful as always, thank you again. > You appear to want ... just insane. With another person, I begin to believe I'm communicating only when I hear that person echo back to me in their own words what I meant to say. I can still believe we're communicating even if along the way I'm judged insane. Yes personally I live close to the brutal fact that code written by host and device people commonly does disagree over what byte count is implied by particular Cdb. Yes more over rare Cdb's than over common Cdb's. Yes more over byte counts and over block size than over block counts. Yes more over data moving in than over data moving out. Yes inescapably only for Cdb's invented after the host or the device shipped. Yes more easily seen in a bus trace of the open & generic flavour of UsbMass (x 08 XX 50) than in a bus trace of Ide. But host & device folk do commonly disagree over byte counts, aye. > <[EMAIL PROTECTED]> > This is simply not true ... > via the command bytes ... If you just say life shouldn't be this way, and I just say it is, and you just say it shouldn't be, and I just say it is, we have nothing further to say. I'm trying to say something more. > Switching to AtapiUDma from AtapiPio > introduces a different kind of assymetry > into the negotiation of byte counts transferred. > > In AtapiPio, > the host can end the data transfer > on any 16-bit "word" boundary > and the device can end the data transfer > on any byte boundary. > > In AtapiUDma, > the sender ... can end the data transfer > on any "word" boundary > but the receiver ... can only end the transfer > after as many as X unwillingly requested words > cross the bus. Do we here have the seed of a consensus? > <[EMAIL PROTECTED]> > ... In all ases > the device can halt the transfer of data > when it runs out by terminating the DMA burst Yes, and no, by data transfer mode. An Atapi device can end a data transfer: Pio: any byte boundary SwDma: any 16-bit "word" boundary MwDma in practice: any 16-bit "word" boundary MwDma on paper: after at most 3 more bytes clock across the bus UDma In: any 16-bit "word" boundary UDma Out: after at most X * 2 + 1 more bytes clock across the bus An Atapi host can end a data transfer: UDma In: after at most X * 2 + 1 more bytes clock across the bus (all other modes): any 16-bit "word" boundary Can we say now we debate only how rarely or commonly people should care about these Pio/Dma differences? No longer are we debating what these Pio/Dma differences are? > The host and device > NEVER negotiate the number of bytes > to be transferred per command I'm saying in practice the i/o API's of Microsoft Windows & friends make independent the Cdb and the max count and required direction to move data. I'm saying when you give human programmers a degree of freedom, they exercise it. I'm saying part of what makes AtapiPio mostly work more than AtapiDma is that AtapiPio includes protocol for the device to echo back to the host precisely what the byte count is. > The Host always DEMANDS, ... > the exact number of bytes > the device must receive on writes (data out), ... > the host DEMANDS > the exact number of bytes read ... By inserting the "..." ellipses I've constructed a hypothesis we can readily falsify in the lab. I'm saying in practice the i/o API's of Microsoft Windows & friends make independent idea of passed/not status (think Atapi ERR aka CheckCondition) from the idea of "residue" i.e. the count of bytes expected to move that did not move. There, to claim that a host demands an exact count of bytes is to claim that host sofware sees nonzero residue as passed-not status. Commonly Microsoft hosts do not. By the way, with Microsoft the residue reult is an OPTIONAL result. Lots of hosts don't even fetch it, much less branch on it. We see the reckless disregard of nonzero residue most visibly when a Mac or Linux or Sun or ... or embedded or ... host chokes over a device behaviour that Microsoft glibly swallowed, by way of the host programmer in question having been silly enough to implement the published spec. > it is only with > device specific control information > that the device > is allowed to transfer fewer bytes > than the host allocated space for. This hypothesis we can readily falsify as written, with an widely available counterexample. Take a look at the op x12 Inquiry data of the emulated Scsi view that Microsoft Windows NT/XP provides for your Ata boot drive. There the first eight bytes do not transfer: the host always ends with whatever the host had originally in the i/o buffer. In particular, the "additional length" byte the host sees at offset 4 after the command is whatever the host put there to begin with. How then can it be that op x12 Inquiry mostly works in Microsoft Windows? Why doesn't the indeterminate "additional length" bring everything down with a crash? Because Microsoft doesn't care what the additional length is, no more than they care if the residue is nonzero. Pat LaVarre P.S. I still hope to return to answer individually the whole burst of traffic under the last subject line, so here we have perhaps slightly less provocative subject line. Subscribe/Unsubscribe instructions can be found at www.t13.org.
