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 > > http://members.aol.com/plscsi/ftf.html > Pat: I have not read your document yet but I will. Thank you (and everyone else here) for the gift of your time. > Pat: I have not read your document yet but ... > ... ... ... I see confusion here. Yes. > ATA/ATAPI is built upon the idea > that both host and device know > how much data all possible "write" > commands will transfer. > And upon the idea that "read" commands > have a maximum transfer size > but that in a few cases a device > might transfer less than that maximum. Cogent, thank you. > In my opinion trying to make ATA/ATAPI > work like some other interface > shows a lack of understanding > of the basics of ATA/ATAPI. In my opinion, trying to think of Atapi as anything other than yet another Scsi transport shows a lack of understanding of the basics of I/O subsystem design for a plug 'n play O.S. > a lack of understanding of the basics I'm saying nobody who matters actually includes, in a plug 'n play O.S., a model specific to Ata/pi for forecasting how many bytes the device will ask to copy which way. There's no standard place to claim, for example, that a particular Atapi device will copy In 6 bytes via Atapi Dma if it would have copied In 5 bytes, given precisely the same -x 12 0 0 0 05 0 "Inquiry of additionalLength" command. Accordingly, actual people instead learn to say "just use Pio" when copying anything but block data. > a model specific to Ata/pi > for forecasting how many bytes Suppose someone did include such a model. Many storage device folk wouldn't like the consequences. Device folk like having the plug 'n play O.S. help share the us with other devices. They like having the O.S. read and run code from the media without forcing the customer to acquire and install a vendor-specific driver. They like adding value later with vendor-specific commands. Achieving these design goals implies committing to use a generic bus driver - a bridge written by O.S. folk, not by device folk. That generic bus driver is by definition blind to the meaning of the command. An example generic API appears as the plscsiCall entry point of http://members.aol.com/plscsi/scsiany.html To program a generic bus driver, you specify the bytes of the command independently of your limit on how many bytes to agree to copy which way. These values are separate and therefore by definition independent, not correlated, entirely subject to the quality of the software that generates them. Then let's remember the Ata & Scsi traditions of halting data transfer prematurely just because an error occurred, and the Scsi tradition of cutting data In short more often than that. These pointless traditions regrettably, but unavoidably, make any host guess of how many bytes the device will agree to copy sometimes too large. http://members.aol.com/plscsi/ftf.html exists to present a scheme for comparing one Scsi transport with another, sorted to present the actual consequences of this lack of correlation from the most commonly to the most rarely observed. Pat LaVarre
