Re: Kernel Summit request for Discussion of future of ATA (libata) and IDE

I'm using gmail's interface (I don't have access to my laptop ATM) so
the mail may look a bit weird...

On Sun, Aug 3, 2008 at 5:57 PM, James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
Right at the moment, we have two separate subsystems for running IDE
type devices: driver/ide and drivers/ata. The claim I've seen is that
drivers/ata can do everything drivers/ide can do plus it does sata. I

This claim doesn't seem to have confirmation in facts:

* There is still hardware that is simply not-supported by libata at all:

- architecture specific hardware (ppc, m68k, mips, arm)

- "difficult" legacy PC-class hardware (i.e. secondary interface on
CY82C693 etc)

* There are still regressions in many libata PCI host drivers dating back
to their rushed introduction.

* There are still corner case in libata core - PIO is dead slow
compared to drivers/ide/,
"serialized" hosts are not supported, some quirks for obsolete
hardware got lost...

also note that no major distribution seems to enable anything in
drivers/ide anymore, so given this is it time to deprecate drivers/ide?

Major distributions make their own decisions (I don't remeber anybody from
these distros discussing the conversion on linux-kernel or linux-ide) which
sometimes don't match with what kernel.org kernels are doing.

[ Actually one distro went so far as CONFIG_IDE=n even before support for
all PC-class IDE PCI hardware present in drivers/ide was available
in libata. ]

Also the same major distros that use libata on x86 are using
drivers/ide on non-x86.

A counter argument to the above is that not all drivers (particularly
the older ones where hw is scarce) are converted to drivers/ata, so
drivers/ide seems to be needed for some legacy systems (in which case it
can be deprecated but not removed). I've also noted that some embedded
distributions seem to be using drivers/ide, but I'm not really sure
whether this is inertia or some overriding need.

drivers/ide deprecation would be a premature thing.

The proposal is to discuss the future of these two subsystems and arrive
at a consensus what's happening to each going forwards.

Well, I'm looking forward to discuss the future of Linux ATA support.

Thanks,
Bart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
    ... Benjamin Herrenschmidt wrote: ... a higher level instead but I suppose what you propose is easier. ... the above would have the advantage of not relying on drivers/ide ... pmac ide to libata). ...
    (Linux-Kernel)
  • Re: Kernel Summit request for Discussion of future of ATA (libata) and IDE
    ... drivers/ata can do everything drivers/ide can do plus it does sata. ... For PC class hardware libata covers everything in old IDE and a lot ... For the older Mac hardware libata does not have pre PCI Macintosh ... There is a trend in new hardware to interfaces that simply won't fit old ...
    (Linux-Kernel)
  • Re: Merging libata PATA support into the base kernel
    ... an option to someday provide /dev/hd* symlinks for PATA devices when ... and a different set of ioctls. ... And libata already has sufficient ioctl compatibility for nearly all ... purposes with the old drivers/ide stuff. ...
    (Linux-Kernel)
  • Re: Abysmal PATA IDE performance
    ... Remove the drivers/ide stuff from you system and let libata ... manage the ICH7. ... Please read the FAQ at http://www.tux.org/lkml/ ...
    (Linux-Kernel)
  • Re: PATA drivers queued for 2.6.19
    ... drivers/ide IS STILL THE PATA DRIVER SET THAT USERS AND DISTROS SHOULD CHOOSE. ... Alan> Except optionally for the following for chips not handled by or broken ...
    (Linux-Kernel)