RFC: moving drivers to a new drivers/ata directory
Eventually I would like to move libata, and a few non-libata driver like 3ware, to drivers/ata. It would appear in the makefile (and link order) _after_ drivers/ide and drivers/scsi.
Comments/objections?
Jeff
Quoted 6 lines · Jeff Garzik
Eventually I would like to move libata, and a few non-libata driver like 3ware, to
drivers/ata. It would appear in the makefile (and link order) _after_drivers/ideanddrivers/scsi.Comments/objections?
Only if your stop using the scsi subsystem. The handfull scsi drivers outside drivers/scsi are a pain already.
Quoted 9 lines · Christoph Hellwig
Quoted 3 lines · Jeff Garzik
Eventually I would like to move libata, and a few non-libata driver like 3ware, to
drivers/ata. It would appear in the makefile (and link order) _after_drivers/ideanddrivers/scsi.Comments/objections?
Only if your stop using the scsi subsystem. The handfull scsi drivers outside
drivers/scsiare a pain already.
Welcome to the real world, where SCSI drivers can be for non-SCSI hardware, and where SCSI hardware can also drive non-SCSI devices.
Fix your subsystem, if it can't support SCSI drivers outside of drivers/scsi.
Jeff
Quoted 5 lines · Jeff Garzik
Welcome to the real world, where SCSI drivers can be for non-SCSI hardware, and where SCSI hardware can also drive non-SCSI devices.
Fix your subsystem, if it can't support SCSI drivers outside of
drivers/scsi.
It's not about not working but making life for the scsi maintainers easier.
Quoted 8 lines · Christoph Hellwig
Quoted 3 lines · Jeff Garzik
Welcome to the real world, where SCSI drivers can be for non-SCSI hardware, and where SCSI hardware can also drive non-SCSI devices.
Fix your subsystem, if it can't support SCSI drivers outside of
drivers/scsi.It's not about not working but making life for the scsi maintainers easier.
SCSI drivers outside drivers/scsi are going to continue to be a fact of life... And if that is the case there shouldn't be much of a demonstrable difference between drivers/scsi... except for the obvious times when drivers/scsi is used but is inappropriate.
Jeff
PATAPI via libata promise 20275 (was: RFC: moving drivers to a new drivers/ata directory)
Continuing down a somewhat related path, what is the outlook for PATAPI via libata?
There is a high level of interest to have hotplug controllers for ppc64, and the primary (exclusive at this point) application is to drive PATAPI optical.
I know you have indicated that you have some WIP to get there. I would like to offer any help to reach that goal.
Would you point me to any code available?
++doug
Re: PATAPI via libata promise 20275
Quoted 8 lines · Doug Maxey
Continuing down a somewhat related path, what is the outlook for PATAPI via libata?
There is a high level of interest to have hotplug controllers for ppc64, and the primary (exclusive at this point) application is to drive PATAPI optical.
I know you have indicated that you have some WIP to get there. I would like to offer any help to reach that goal.
Would you point me to any code available?
You should be following linux-ide, and pay attention to any posting like
http://marc.theaimsgroup.com/?t=109782787200002&r=1&w=2&n=4
The latest ATAPI code is currently in the latest -BK snapshot of upstream, but new development occurs in "libata-dev" queue as described in the above email link.
Jeff
Re: PATAPI via libata promise 20275 (was: RFC: moving drivers to a new drivers/ata directory)
In reply to Doug MaxeyATAPI is working just fine for me (ata_piix) in both PIO/DMA and thanks to Jeff all my ATAPI work is now in -linus tree. :)
Just enable ATA_ENABLE_ATAPI in <linux/libata.h>.
Quoted 12 lines · Doug Maxey
Continuing down a somewhat related path, what is the outlook for PATAPI via libata?
There is a high level of interest to have hotplug controllers for ppc64, and the primary (exclusive at this point) application is to drive PATAPI optical.
I know you have indicated that you have some WIP to get there. I would like to offer any help to reach that goal.
Would you point me to any code available?
++doug
Quoted 4 lines · Jeff Garzik
Eventually I would like to move libata, and a few non-libata driver like 3ware, to
drivers/ata. It would appear in the makefile (and link order) _after_drivers/ideanddrivers/scsi.Comments/objections?
A comment: if SAS HBAs ever get installed on motherboards then it won't be obvious to the average user which susbsystem they should configure (i.e. ATA/SATA or SCSI/SAS). In both cases an internal SATA disk could be connected via a SATA cable to a plug on the motherboard.
So if you do move the drivers to the ata directory it may be useful to stress that it is the category of HBA that is signficant rather than the device at the far end of the cable.
Doug Gilbert
Quoted 5 lines · Douglas Gilbert
Quoted 3 lines · Jeff Garzik
Eventually I would like to move libata, and a few non-libata driver like 3ware, to
drivers/ata. It would appear in the makefile (and link order) _after_drivers/ideanddrivers/scsi.
Quoted 8 lines
Quoted 1 line
Comments/objections?
A comment: if SAS HBAs ever get installed on motherboards then it won't be obvious to the average user which susbsystem they should configure (i.e. ATA/SATA or SCSI/SAS). In both cases an internal SATA disk could be connected via a SATA cable to a plug on the motherboard.
I don't think it matters if the HBA is on the motherboard or not. Since SAS can support attaching SATA and SATA/ATAPI devices via STP, we could certainly end up with HBAs that support both SAS and SATA devices. Where would such a driver exist? If libata moves into the ata directory, it seems like it would be more difficult for a single LLD to support both SAS and SATA.
Signature · 3 lines
Brian King eServer Storage I/O IBM Linux Technology Center
Quoted 14 lines · Douglas Gilbert
Quoted 4 lines · Jeff Garzik
Eventually I would like to move libata, and a few non-libata driver like 3ware, to
drivers/ata. It would appear in the makefile (and link order) _after_drivers/ideanddrivers/scsi.Comments/objections?
A comment: if SAS HBAs ever get installed on motherboards then it won't be obvious to the average user which susbsystem they should configure (i.e. ATA/SATA or SCSI/SAS). In both cases an internal SATA disk could be connected via a SATA cable to a plug on the motherboard.
Quoted 3 lines
So if you do move the drivers to the ata directory it may be useful to stress that it is the category of HBA that is signficant rather than the device at the far end of the cable.
That implies that scsi is an acceptable appelation for ATA controllers?
Maybe we need a neutral one like 'drivers/storage'.
Jeff
Quoted 1 line · Jeff Garzik
Maybe we need a neutral one like '
drivers/storage'.
Where does that leave usb, firewire or i2o 8). At the end of the day the only "perfect" division is a single directory "drivers", and that doesn't work.
Having drivers/ata seems a decent approximation.