This message is from the T13 list server.
Curtis Stevens wrote:
My point is that the information is available to the bridge when the CDB is received. I do not think we want to get into specifying the intervening layers, there are many possible models. Software-wise, there is no difference between PIO multiple and PIO. In both cases the ATA host needs the DRQ block size. This will tell him how many blocks/interrupt to transfer.
In both my own software and in several vendor-written drivers, there _is_ a difference in code paths between PIO and PIO-Mult. Just look at the code that's out there.
I also do not believe the transport can be separated from the CDB because this has the transfer length in addition to the direction. While I could place the protocol field in the CDB, there is no room for the length. The ATA host also needs this information to properly complete a PIO transfer. For DMA transfers, this information may also be necessary for buffer size allocation, although some implementations could do it without buffers.
Er, huh?
Every ATA read/write command specifies transfer length and data direction already. No need to store or derive that information elsewhere.
The reason I included the goals is that, given the applications I stated,
queuing is not required. I am a member of the drive product team and
understand the limitations. However, support of queuing would require
asynchronous status notification by the bridge to the application. I don't
think we really need to go there at this time. If this pass-through becomes
wildly successful and starts to be used in a performance environment, then
we can upgrade it to provide more capability.
I would prefer that we get it right the first time ;-)
ATA passthru can and will be used to verify the correctness of the underlying OS driver, bypassing all translation layers.
Lack of support for queueing, etc. prevents such verification.
Jeff
