This message is from the T13 list server.
>On Mon, 15 Apr 2002 16:22:26 -0600, Pat LaVarre wrote: >This message is from the T13 list server. >Your error here is to think the Cdb is the whole "command". >Viewed in the light of the most basic precepts of computer i/o, >it isn't the WHOLE command. But it *is* the *whole* command, it is the only thing most devices get from the host. If fully defines what the device is expected to do including the direction of data transfer and the amount of data. >To a classically trained programmer, what's bizarre about many >Scsi-over-whatever protocols, and T13 Atapi protocol in >particular, is that these protocols do not include in the >"command" a plain indication of how many bytes to copy which way. This is completely out of the context of the ATA/ATAPI interface and the actual bus transactions that happen as part of the command execution on the ATA interface. This extra information is provided by host application programs to the host OS device driver stack as part of good software design, to insure system and application data integrity and so that the OS device driver stack is not required to fully understand every device command. Even my ATADRVR software has these parameters in the reg_packet() function call (in file ATAIOREG.C). This is not a discussion that should be taking place on the T13 email list. I don't think most T13 members care much about the internal software design of OS device drivers. >As a device, all you get is the Cdb, in place of what you need. >So you're stuck patching up life afterwards. What more does a device need? Does a SCSI 00H command ever transfer data? Is a SCSI 12H command ever a write command? Is a SCSI 2AH command ever a read command? When does a Read 10 command tell a device to transfer more than N blocks of current_device_block_size bytes? If we believe what you say, then all commands result in random device activity. That would be nothing but chaos. But we know that isn't the way the world works. >Because "everyone knows" the Cdb does not plainly indicate how >many bytes to copy which way. Good grief. Why has T9, T10, t13, etc, spent all these years defining all these CDB values? If any given CDB is nothing more than random data that can be ignored then what is the point of having industry wide specifications and standards? >Take the now familiar example of Cdb -x 12 0 0 0 05 0. In >unambiguous English, Ansi T10 claims this Cdb means copy between >0 and 5 bytes In. But the trivially repeatable trace >http://members.aol.com/plscsi/20020328/oddwinme.txt shows that >Windows often decides instead to copy In 8 or 6 bytes, not just >5. OK, but this is a Windows driver stack issue. And for all I know the Windows driver documentation tells why this happens. I'm sure it is not some random action just to confuse us. Sure, maybe it is poor software design or even a bug that should be fixed but it has nothing to do with the ATA interface or the actual exection of ATA or ATAPI PACKET commands on the ATA interface. >All that pretty fiction published by Ansi T10 has no place in >something as real and essential as an Ansi T13 specification. Pat, I'm not sure we have anything to discuss or resolve. At least not anything we can discuss here that is going to result in a change to T13 ATA/ATAPI. You have your own definition of SCSI and that doesn't seem to match the rest of the world. You talk about Ultra DMA residue bytes when there is never more than one such byte and it is documented as being a "Pad" byte. You talk about command results that can only happen when a host or device in incorrectly implemented, such as, a device that expects more data or sends more data than defined by the command. T13 isn't going to fix something unless it is a real world problem. I'm sorry to say, the issues you raise just don't seem to be real world problems. Yes, they may be problems for broken hosts or broken devices. But T13 (and T10 too) are probably not going to make some major change just because someone has shipped a broken host or device (even Microsoft, Apple and other big and powerful companies understand this). *** Hale Landis *** www.ata-atapi.com ***
