This message is from the T13 list server.
Jeff Garzik wrote:
This message is from the T13 list server.
If the underlying command set doesn't handle queuing, then you don't get
a whole lot of useful queueing. In the standard command set (sidebar:
why is ATA/ATAPI so vague about calling it SCSI?), SCSI, there is some
notion of task [queue] management.
Isn't this a vendor's 'device implementation' choice? What makes a SCSI
command set meet your requirement of 'supporting queuing'? What does
this have to do with the location of the (host selected) command tag
value in the command parameter information sent to the device? Why/how
does the existing PACKET command's tag value location (in Sector Count
bits 7-4) inhibit a good command queuing implementation in a device?
Certainly there are specific state sequences considered to be standard
SATA, for the purpose of ATA command protocol(s) execution, but the
underlying technology is nothing but a packet-shuffling point-to-point
network link.
So you are confirming the views of many people that think SATA has very
little to do with ATA or the traditions of or standards for ATA. It is
just another 'serial interface' that has been given the confusing and
inappropriate name of 'serial ATA'. All the more reason to stop
producing new documents that describe the stable PATA interface, kill
T13, and let the secret society do whatever its wants to do in an
attempt to build some kind of new and different serial I/O interface
(that should not use the ATA name).
BTW There have been several uses of ATA (PATA) that are non-standard -
used to talk to strange (non-disk) devices using register access
patterns that look nothing like the standard PATA command protocols. But
we don't call these ATA hosts or ATA devices. Hosts and devics using
SATA to transport random and 'non-standard' packets should also not use
the ATA name).
--
++ Hale Landis ++ www.ata-atapi.com ++
