Command Queuing and ATA (PI)

Charles Monia, SHR3-2/W4, 237-6757, 12-Feb-1994 0002 monia at
Fri Feb 11 21:01:35 PST 1994

Jim McGrath wrote:

>ATAPI is the new protocol to send SCSI command sets accross the ATA physical 
>interface - it is already being used for CD-ROMs.  In addition, normal ATA 
>commands could do with a queuing enhancement.

>SInce there is a software developers desire to make the physical interface 
>transparent to the software writer, and since ATA is the largest volume disk 
>drive interfaces, and since it will co-exist with SCSI on a lot of systems, you 
>would want to leverage code.
>My problem with SAM requiring all the features is that does this allow a
>SCSI-3 compliant interface standard to say things like: to get ordered
>command operation, simply send down the commands one at a time?
>Or does this require that interface to provide something similar to ordered
>queue tags?  Since the queue tag concept cannot be directly mapped to another
>interface anyway (e.g. SPI uses messages, serial uses frames, etc...),
>is there anything wrong with just saying: to get this SAM specified feature,
>use host throttling, etc...  Realizing that this is not a technically
>clear interface.

First, contrary to my earlier note which was in error, there are no words in
SAM requiring a target implementation that supports queuing to support all the
queuing functions. As far as I can tell, there are no words in the text of the
queuing model passed by the committee either (X3T9.2/92-141R6). (If there are,
then I stand corrected and SAM must, of course, be revised accordingly.) Unless
I'm mistaken then, I believe this issue must be addressed by the committee.

Anyhow, in my personal opinion, it is reasonable for an ATA(PI) implementation
to emulate the SCSI-3 model in host software using some simplified queuing
mechanism within the device, such that an existing SCSI driver will run without
modification. Since such a system does not have to deal with the
equivalent of a multi-initiator environment, I believe it's possible to
provide a driver software interface, ala the CAM SIM layer, that's
indistinguishable from an SCSI-3 environment.

I believe what's needed in SAM is a statement that compliance shall be
determined by behavior observed at the interface between the application
client (e.g., a CAM device driver) and the service delivery subsystem (e.g.,
the CAM SIM layer). I'll prepare a proposal to that effect for discussion
at the next X3T10 meeting.

Comments, Brickbats...


More information about the T10 mailing list