[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080803173941.314edf33@lxorguk.ukuu.org.uk>
Date: Sun, 3 Aug 2008 17:39:41 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: ksummit-2008-discuss@...ts.linux-foundation.org,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-ide <linux-ide@...r.kernel.org>
Subject: Re: Kernel Summit request for Discussion of future of ATA (libata)
and IDE
On Sun, 03 Aug 2008 10:57:35 -0500
James Bottomley <James.Bottomley@...senPartnership.com> 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
> also note that no major distribution seems to enable anything in
> drivers/ide anymore, so given this is it time to deprecate drivers/ide?
>
> 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
That statement would be false. In fact for old and obscure hw the libata
coverage is probably better, not that this in fact is the slighest bit
relevant to the real world!
The current situation is something like this
- For PC class hardware libata covers everything in old IDE and a lot
more.
- For the older Mac hardware libata does not have pre PCI Macintosh
support although it is in progress
- For certain embedded PPC boards there are some things to sort out with
IRQ routing on non standards sane configurations using pata_ali in
particular.
There is a trend in new hardware to interfaces that simply won't fit old
IDE so that process of libata only drivers is likely to continue.
> 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.
Actually what a material number of embedded systems need is a single
dumb-as-a-rock CF only PIO driver which doesn't suck in large chunks of
midlayer code. I'm just not sure that trend will continue as CF is giving
way to other smaller media.
> The proposal is to discuss the future of these two subsystems and arrive
> at a consensus what's happening to each going forwards.
Won't be at KS and I suspect that is true of most of the folks hacking on
both sets so the right place for discussion would be the net. Right now
the PPC bits need fixing, and the lack of libata Macio support for the
moment makes the debate premature.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists