At the risk of boring you but informing others, Serial Attached SCSI (SAS) is going to muddy things.
Not necessarily... ;-)
But yes, I am keeping track of SAS, don't worry.
The SCSI ATA Translation (SAT http://www.t10.org/ftp/t10/drafts/sat/sat-r04.pdf ) draft hopefully will find application any many areas other than libata (e.g. USB mass storage and 1394's SBP-2 drivers). The Scope section (section 1) of that draft makes interesting reading: in point a) the author sees SAT as presenting a unified command interface for block type devices across PATA, SATA and ATAPI!
In Linux's case, libata's SCSI<->ATA translation is merely a convenience so that I didn't have to bother writing all that storage infrastructure at the block layer. And SAT was merely a convenient standard I could follow during the exercise.
However the primary reason that SAT started is the fact that SAS infrastructure can include SATA disks. SAS defines the Serial ATA Tunneled Protocol (STP) which in linux will first appear in a SAS LLD (i.e. a scsi subsystem Low Level Driver, something like aic7xxx). Connecting a SATA disk (transported via SAS) to the IDE subsystem and a /dev/hd? device node seems like an unnatural act (a bit like ide-scsi in reverse). A solution involving libata seems appropriate in this case.
Certainly there will be hardware that attaches to both SATA and SAS. I've been planning for this. I even have an Adaptec card (and docs).
It depends highly on the LLD how this is implemented. If a SCSI interface to SATA is forced upon us (i.e. SAT is implemented in a firmware somewhere), then there's not much you can do.
If the LLD provides direct access to either SCSI CDBs or ATA taskfiles (FIS's), then the OS should directly work with the device's native command set. Far from adding value, translation actually hinders progress, as users must either (a) find a way around the SAT layer to access an ATA feature, or (b) wait until the SAT layer is updated to support a translation for the desired feature.
One of the biggest requested features for libata is "ATA passthru", the ability to directly submit ATA commands to the device. That should tell you something about what -users- want.
SCSI and ATA are competing and evolving command sets, which implies that there is -increased- interest in -not- hiding ATA devices behind an emulation layer.
A SATA+SAS LLD would ideally register an instance of the SAS transport class with the SCSI layer, and an instance of the SATA transport class with the block layer. That's all it needs to do.
Everything else -- /dev/hdX versus /dev/sdX, emulation, sd/sr/st, etc. -- are all clients to either a SATA or SCSI transport class. Remember, to many users, the fact that SATA right now uses /dev/sdX is confusing and annoying: they would prefer /dev/hdX as IDE has been presenting for over a decadce.
With the right design, there is little value OR NEED in hiding ATA devices behind emulation.
Even more likely is that a SAT layer will be implemented in SAS enclosures just inches away from lots of SATA disks. From the point of view of a linux machine such SATA disks talk the SCSI command set and are connected via a SAS transport (Serial SCSI Protocol (SSP)). The only things that will probably care about the difference between such SATA disks and SAS disks are utilities like smartmontools (and that gap is being partially closed as well).
Linux will always want to talk to a device in its native command set, unless a firmware _forces_ us to do otherwise.
If the user considers a SAT layer added value, then they can certainly use such at their site.
Perhaps libata could be renamed libsat.
s/libata/libata-scsi/
libata core is a SCSI-independent ATA transport, approaching the "ATA transport class" that I described above.
Jeff
- : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
