RFC: moving drivers to a new drivers/ata directory

RFC: moving drivers to a new drivers/ata directory

[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/ide and drivers/scsi.

Comments/objections?

	Jeff

Re: RFC: moving drivers to a new drivers/ata directory

[Christoph Hellwig]

On Fri, Oct 15, 2004 at 12:51:35AM -0400, Jeff Garzik wrote:
> 
> 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?

Only if your stop using the scsi subsystem.  The handfull scsi drivers outside
drivers/scsi are a pain already.

Re: RFC: moving drivers to a new drivers/ata directory

[Douglas Gilbert]

Jeff Garzik wrote:
> 
> 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?

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

Re: RFC: moving drivers to a new drivers/ata directory

[Brian King]

Douglas Gilbert wrote:
> Jeff Garzik wrote:
> 
>>
>> 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?
> 
> 
> 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.


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center

Re: RFC: moving drivers to a new drivers/ata directory

[Jeff Garzik]

Douglas Gilbert wrote:
> Jeff Garzik wrote:
> 
>>
>> 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?
> 
> 
> 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.


That implies that scsi is an acceptable appelation for ATA controllers?

Maybe we need a neutral one like 'drivers/storage'.

	Jeff

Re: RFC: moving drivers to a new drivers/ata directory

[Jeff Garzik]

Christoph Hellwig wrote:
> On Fri, Oct 15, 2004 at 12:51:35AM -0400, Jeff Garzik wrote:
> 
>>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?
> 
> 
> Only if your stop using the scsi subsystem.  The handfull scsi drivers outside
> drivers/scsi are 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

Re: RFC: moving drivers to a new drivers/ata directory

[Alan Cox]

On Gwe, 2004-10-15 at 18:20, Jeff Garzik wrote:
> 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.

Re: RFC: moving drivers to a new drivers/ata directory

[Christoph Hellwig]

On Fri, Oct 15, 2004 at 01:22:15PM -0400, Jeff Garzik wrote:
> 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.

Re: RFC: moving drivers to a new drivers/ata directory

[Jeff Garzik]

Christoph Hellwig wrote:
> On Fri, Oct 15, 2004 at 01:22:15PM -0400, Jeff Garzik wrote:
> 
>>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)

[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

Re: PATAPI via libata promise 20275

[Jeff Garzik]

Doug Maxey wrote:
> 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)

[Bartlomiej Zolnierkiewicz]

ATAPI 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>.

On Thu, 21 Oct 2004 12:04:45 -0500, Doug Maxey <dwm@maxeymade.com> wrote:
> 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