This message is from the T13 list server.
> Subject: Re: [t13] re why count bytes - please Pat shut up already? > From: Hale Landis > Date: Thursday - April 11, 2002 5:52 PM > ATA/ATAPI ... I don't know anything about USB > but from Pat's comments ... > these same data integrity problems. > ... 1394/SBP2 ... Sorry I was unclear. I mean to be saying ... Generic Usb Mass in effect just moves the Pci/Ide bridge off of the motherboard, down the Usb cable, to be controlled remotely. A Usb/Ide bridge can thus offer just as much data integrity as a Pci/Ide bridge. No more, no less, when we're speaking as abstractly as this. Some implementations offer more integrity by using a printed circuit board in a sealed box rather than a cable in an open box that ignorant customers mess with. In generic Usb Mass, the Usb host programs the bridge to copy bytes. The Usb host says which way to copy how many bytes, the bridge reports back how many bytes it did copy. The bridge can also report that it has halted, waiting for a reset, when the device asked to copy too many bytes, when the device asked to copy bytes the wrong way, when BSY DRQ C/D I/O don't agree, etc. etc. The generic Usb Mass spec doesn't require a Usb/Ide bridges to be as transparent as a typical Pci/Ide bridge - but the bridge can be that transparent. Internally, our standard for a Usb/Ide bridge is that no problems appear with that bridge that don't also appear with Pci/Ide bridges. The first bridge we shipped, developed by subcontract, met this standard except for some errata, hopefully rare in practice. The later bridges meet this standard without caveat, or we ship an old bridge instead. 1394:Sbp2 cannot be this transparent. Sbp2 has no standard for reporting the count of bytes copied and Sbp2 has a tradition of copying In as many bytes as the host allows. Atap UDma cannot be quite this transparent. Atapi UDma requires the sender to fabricate an extra byte whenever the byte count is odd and licenses the receiver to discard without complaint the last few bytes covered by the last Crc of the data of a command. Pat LaVarre
