This message is from the T13 list server.
Since I didn't post for a week, maybe I can usefully contribute Two replies. > From: Hale Landis [[EMAIL PROTECTED]] > Sent: Thu 1/16/2003 10:33 AM > * Part 2 - CDBs with odd data transfer > > So how does ATA/ATAPI deal with SCSI CDBs that > attempt to transfer an odd number of bytes? The > answer is based upon the fact that at the hardware > level and at the lowest level of an OS device > driver stack there is no such thing as an odd > length data transfer - all data transfers are for > an even number of bytes (PIO and DMA). Same ambiguities as detailed previously. > The answer is that if there is to be an odd length > data transfer only the CDB data can imply that > (perhaps with an Allocation Length field value that > is an odd number). No. For example, the cdb[4] AllocationLength of an op x12 Inquiry tells us only the max count of bytes a compliant device may ask to copy In. Whether the max count is odd or not tells us nothing of whether the device is actually asking to copy In an odd count or not. Only the odd x1F5:1F4 Byte Count that tells us that. > The answer is that only the application program > that built the CDB or some higher level part of the > OS driver statck that is attempting to execute the > CDB knows the data transfer is an odd length. No, only the device knows. A Scsi pass thru protocol that lets the device share that info has a competitive advantage over a protocol that does not. > On the device side the only indication of a odd > length transfer comes from looking at the CDB data. No, this varies by protocol. In Atapi Pio, the count of pad bytes is the x1F5:1F4 Byte Count and'ed with x0001. In vendor-specific Atapi Dma solutions, the count of pad bytes might be the x1F5:1F4 Byte Count sampled at Status In time. In standard Atapi Dma, as yet there is no way for the device to share its knowledge of how many pad bytes clocked across the bus. > At some level within the OS device driver stack > there must be an understanding of how to handle > this odd transfer length request vs. the even > transfer length requirement of the ATA/ATAPI > interface. No more magic in the OS than anywhere else. Saying that something "must be" doesn't bring it into existence. Anyhow, this thinking is backwards. It's not like the new Ata/pi Dma standards came out and then the OS was redesigned to fit. In fact, Scsi came first and everyone followed. (Except also, Ata came before that, and noone followed - too brittle e.g. required host & device to agree in advance over how many bytes to copy which way.) Pad bytes have been harmless in Ata/pi because Win 95 B always guaranteed at least one, and because Pio often remains an option when the command is not a read/write op known to need the thruput of Dma. Not because anyone knows how to count them in Atapi Dma. > If an OS driver stack claims to support CDBs with > odd data transfers then that OS driver stack must > be properly implemented. It is properly implemented, whenever the Scsi pass thru protocol in question is properly supportive. In fact, Windows always claims to be able to count pad bytes, but returns a false claim of zero for busses that don't support counting pad bytes. > There is nothing that can be changed in the > ATA/ATAPI-x standards to fix the problem of an > incorrectly implemented OS driver stack (or > application program). The standards can grow to allow the device to share what only the device knows. Hosts can then compete on the basis of how competently they respond to such intelligence. > * Part 3 - "x" interface to ATA/ATAPI bridge devices To this I will return, if helpful. I trust we remember that the OS driver is also a bridge, like any other, just implemented entirely as software, with no hardware involved. Thanks in advance, hope this helps. Pat LaVarre
