libata, SCSI and storage drivers

Jeff Garzik
2005-05-27T02:49:45Z

Jens Axboe wrote:
> On Tue, May 24 2005, Jeff Garzik wrote:
>
>>Jens Axboe wrote:
>>
>>>On Tue, May 24 2005, Jeff Garzik wrote:
>>>
>>>>I can describe how this will look when libata is divorced from SCSI, if
>>>>you would like, too...
>>>
>>>I was beginning to dispair you had given up that plan...
>>
>>hehe, nope. I promised Linus, and I plan to keep my promise :)
>
>
> You promised me, too :)
>
>
>>I know how to do it. Internally things have been kept as separate as
>>possible from the SCSI layer.
>
>
> We should start a list of items that could potentially be moved to the
> block layer that libata currently uses.

Here are the two broad categories of things that immediately come to mind.

1. Hardware in pre-production right now can do SAS or SATA on the same
card. So, real soon, a driver will need to do both SCSI and ATA
depending on runtime conditions.

The SCSI transport class is a very nice way to connect low-level drivers
and the class drivers (disk/cdrom/tape/...). It works well with the
device model, and is modular in just the right location.

I would like to develop ATA transport class(es). In order to work well
with SATA/SAS hardware, there will need to be at least one.

And as I hoped you have guessed..... the ATA transport class should be
a child of the block layer, not the SCSI layer.

2. driver API. Linux SCSI layer provides several services which are
generalized to any "packet transport":
* mapping of devices to protocol buses (domain topology, etc.)
* command queueing
* error handling

For hardware like ATA or I2O, this "send-command" type of API is the
most natural way to implement a low-level driver, particularly if the
core code provides all the necessary queueing/mapping/EH services as well.

This infrastructure is -not- specific to SCSI at all. And it is this
infrastructure that allowed me to bring up libata so rapidly.

Jeff