This message is from the T13 list server.
[Voici the third 4KiB of, whoops, sorry, more like 16KiB.] > ... H ... D ... In informal talk like this, I speak of these two counts as signed magnitudes: positive means bytes moving out from host to device, negative means bytes moving in from host to device. The generic UsbMass protocol communicates the sign separately from the magnitude: bmCBWFlags.Direction 0/1 = out/in is separate from dCBWDataTransferLength. > measurably real ... millions > ... ordinary people can observe In the design of UsbMass, we could only argue from a knowledge of people: all we could say was that when a host person and a device person independently write code to communicate they are likely to disagree creatively without accurately anticipating the details. Now we know what we then hypothesised is in fact real. Aye, in all normal situations, H = D. Aye, when D and H agree in sign but D < H in magnitude, often the device is polite enough to report an error and then often the host is polite enough to distrust all the data. What demands more thought are the remaining situations. What happens when the plug 'n pray process leaves the host and the device in slight disagreement over which bits meant a byte count in what units? We get H != D despite the device seeing no error! Wanna walk thru some concrete real world use cases? 1) I remember seeing an Apple host combine with a mouse to only occasionally zero the trailing bits of a command on its way to a Usb disk drive. The drive saw a request to read/write zero bytes and completed that request without error. The host only knew trouble was at hand because the Usb1/Pio4 bridge was able to report precisely that zero bytes had moved. Scsi/Atapi quite carefully accept a request to read/write zero bytes as a complex form of no-op. I can't remembr if on paper Ata requires an error in this case? 2) I remember seeing a Linux host think it was asking to move the first two bytes of a header while a device thought it was asking to move the whole header. Irony #1: Me, I agreed with the host, but the firmware for the device shipped as binary code only, in rom. Irony #2: An earlier version of the same host had asked for whole headers ... but choked when a popular Wintel Ide Dma connection was found unable to handle D < H with anything less drastic than a 7.5+/-0.5s timeout. Some other device thought the header only contained 2 bytes whenever the media was absent. I've never seen any protocol but Ata have the sense to demand that all transfers to/from a block device be multiples of blocks. I wonder how many of these subtle horrors arise largely from a widespread and misplaced zeal to save memory. 3) I remember seeing PC app's allocate space only for the max number of bytes that a well-known device actually will move in response to a particular command. Those app's do not make room for extra bytes of UDma garbage. Saying sorry we smashed some extra memory is not an error from which they know how to respond determinately, much less recover. If UDma permits the sender to clock garbage, then even a host that double-buffers its i/o can't know how many bytes to move to/from app space. The garbage reaches all the way back to the app, just like the out-of-band communication that decides which bits of the command mean a count of bytes moving which way in what units. [The last 4KiB of 16KiB (this time I counted more carefully) is soon to follow.] Subscribe/Unsubscribe instructions can be found at www.t13.org.
