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
- : 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
