This message is from the T13 list server.
> From: Hale Landis [[EMAIL PROTECTED]] ... > Does Win95B use the CDB to determine the interface > data transfer length (that would be the correct > thing to do) while using the app buffer size > correctly (and not storing past the end)? No, never. A key issue here I agree, thank you. In Mac OF, Linux, Win 95 B/ 98/ 98SE/ ME/ 2K/ XP, Dos, etc., a kernel client decides Cdb, CdbLength, data copy Direction, and MaxDataLength. Kernel clients include filesystems, root-privileged user apps, etc. Code specific to Atapi, Usb, FireWire, etc. just passes the whole bundle thru, more or less robustly. In Atapi Pio bus traces, the MaxDataLength often appears passed thru as the x1F5:1F4 Byte Count limit of the xA0 Packet op. And Usb & FireWire traces often show these same bits passed thru. This de facto standard i/o architecture makes sense if we follow the money. Host folk freeze and ship transport code for each new supported Pci/Atapi bridge. On an independent schedule, device folk introduce newly standard Cdb's and offer old proprietary Cdb's. To allow device folk to add value via newly standard and old proprietary Cdb's, the host folk have to allow a proprietary client to decide the data copy Direction and MaxDataLength occasionally. Having to allow this occasionally means requiring this always, if the host folk write the least possible lines of source code. In Windows, for Ata as opposed to Atapi, the soft Scsi to Ata bridge decides Direction and MaxDataLength. Whether the MaxDataLength inside or outside the Cdb wins varies by op. Looking here now in Win XP, inside wins for op x28 Read10, but outside wins for op x12 Inquiry. > while using the app buffer size correctly > (and not storing past the end)? Not reliably. Doing this correctly would require double-buffering whenever a Pci/whatever bridge might be rounding up a misaligned byte count or rounding down a misaligned buffer address. > would be the correct thing to do I've never seen Anyone do this correct thing - which makes me doubt the value of having T13 write a spec usable by only such a host. I've seen some host folk try to do the correct thing, but they always give up, in time. Most famously, Linux ioctl SG_IO versions 1 & 2 guess CdbLength and data copy Direction from Cdb[0], but version 3 lets the client decide, to allow pass thru of newly standard Cdb's and old proprietary Cdb's. As we speak, the Linux usb/ storage/ is giving up the idea that the Cdb & CdbLength alone decide data copy Direction and MaxDataLength, after having changed the standard Linux filesystems to specify those correctly. As we speak, Mac OS X is trying out the idea that you have to patch the kernel if you want the privilege of authoring your own Cdb's for HDD/ CD/ DVD. I'd say that effort isn't going well, but it's too soon to know. > -x "12 0 0 0 FF 0" -i 256 > And then assume for whatever reason the device > transfers 25 [x19] bytes plus a pad byte (26 [x1A] bytes). > > Will Win95B correctly tell the app that 26 [x1A] bytes > were stored into the app's buffer? Here I don't yet have a complete answer, but I'll share what I know and let you ask again. > bytes ... stored into the app's buffer Me, I directly observe the count of bytes stored by allocating a larger buffer but then not admitting to Win that the buffer contains more bytes. I've never seen a Win response depend on the Cdb, except when the bus trace shows Win is substituting some other Cdb for the client's Cdb, like substituting an op x5A ModeSense10 in place of an op x1A ModeSense6, or substituting Ata for Scsi. I imagine you agree, a correctly implemented device that says -x "12 0 0 0 FF 0" means ask to copy In x19 bytes would accept any of -x "12 0 0 0 19 0" thru to -x "12 0 0 0 FF 0" inclusive as meaning the same thing. For all such Cdb's, the Win response I see is the same. On the web, I have posted a trace of Win 98 rounding up the byte count stored like to x1C from x19 i.e. aligning it to a machine int. I blame the Win driver for the particular Pci-to-Atapi bridge involved there. Round up to x1A (i.e. up to an Ata/pi "word") is common, and universal when using Dma rather than Pio. If I understand correctly, you'd find equally informative the case of a device that responded to -x "12 0 0 0 FF 0" by asking to copy In x29 bytes plus a pad byte. That case appears even in the Scsi standards that demand the device ask to copy In at least x24 bytes. > Will Win95B correctly tell the app that 26 [x1A] bytes > were stored into the app's buffer? Win Api's vary. The older report "residue" i.e. the MaxDataLength minus the count of bytes copied. The newer report bytes of data copied. Often the byte count reported is false: often I see the residue falsely reported as zero, or the byte count of data copied set equal to MaxDataLength. The newer Api's no longer define a way to say byte count unknown, so nowadays the driver may have to lie, when the hardware doesn't report the count of bytes copied and/or the protocol doesn't report the count of pad bytes cycled across the bus to/from memory. I have myself written Dos drivers, with essentially the same "Aspi" Api as Win 95/ 98/ ME, that for Pio do correctly report the count of bytes overwritten, and that overwrite only x19 bytes. Rather than double-buffering the whole transfer, I burst just x18 bytes to memory and then I fetch the last two bytes into a register, where I can easily drop the pad byte and thus arrange to have overwritten only x19 bytes. This is visible on a bus trace as a pause before the last Pio "word" cycles. > a) What will Win95B do with > -x "12 0 0 0 06 0" -i 5 > Will store passed the app's buffer or will it hang? In the Usb/Atapi bridge standard, this is case 7 of 13 ways that hosts and devices commonly disagree over the count of data bytes copied, denoted algebraically as 5 = Hi < Di = 6. Classically, in 8-bit Scsi, this was a "phase error", because the host ran out of buffer while copying data In, so the host wanted to see Status In, but the device is still asking to copy data In. Analogously, in Scsi over Usb, this is reported as bCSWStatus = x02 PhaseError. A maximally polite bridge will copy In the first 5 bytes before freaking out. The standard says no bridge may copy In more than 5 bytes. What Win Atapi does here isn't public, and may not be coherent. If the client doesn't in fact guarantee D <= H, results may vary by vendor of each software or hardware bridge between the client and the device. Hi < Di with Di odd is especially fun in Atapi bus traces because the device thinks everything is ok. The device can't know the host had no place to copy In the last byte. The device can only see that the host agreed to cycle In three data "word"s, no matter whether the host is meaning to copy In 5 bytes or 6. So here we have a PhaseError together with a bus trace that shows we reached StatusIn. We have nothing to trigger on, and that's a problem. Pat LaVarre --- From: Hale Landis [[EMAIL PROTECTED]] Sent: Fri 1/10/2003 2:02 PM [Cc: [EMAIL PROTECTED] by permission] >Suppose an app passes -x "12 0 0 0 05 0" -i 5 thru >Win 95 B to an ATAPI device. (That coded hex is an >Inquiry for up to 5 bytes copied into a 5 byte >buffer. People like 5 bytes because the >additionalLength field appears at offset 4.) I'm curious... a) What will Win95B do with -x "12 0 0 0 06 0" -i 5 Will store passed the app's buffer or will it hang? I guess the question is this: Does Win95B use the CDB to determine the interface data transfer length (that would be the correct thing to do) while using the app buffer size correctly (and not storing past the end)? b) What will Win95B do with -x "12 0 0 0 FF 0" -i 256 And then assume for whatever reason the device transfers 25 bytes plus a pad byte (26 bytes). Will Win95B correctly tell the app that 26 bytes were stored into the app's buffer? Hale
