[Ksummit-2012-discuss] [ATTEND] <ding> "Bring out your dead" <ding>...
paul.gortmaker at windriver.com
Tue Jun 26 22:10:15 UTC 2012
On 12-06-26 05:19 PM, Arnd Bergmann wrote:
> On Tuesday 26 June 2012, Paul Gortmaker wrote:
>> Linus mentioned that perhaps someday we might be able to remove EISA as
>> well. It seems to make sense to me too, given that EISA (at least in
>> x86) was largely confined to 486 and 586 (sub-200MHz) server machines,
>> and largely all crushed out of existence by PCI around 1996. But some
>> non-x86 boxes may rely on EISA -- such as some Alpha boxes, I think.
> Another point on this:
> I think the far more interesting one is removing ISA add-on card support.
> ISA drivers are much more numerous than EISA ones and were typically
> written in times so far back that they don't adhere to any modern coding
> standards any more. Very few people still have systems with ISA slots
> in them, but some of them are probably quite fond of them ;-)
> What I found by looking at Kconfig, these systems might have ISA slots
> (at most):
> * alpha (all?)
> * arm (clps711x, pxa, s3c24xx, footbridge, ebsa-110, sa1100, shark)
> * m68k (q40, amiga)
> * mips (jazz, sni_rm, sgi_ip2x, fuloong2e, fuloong2f, casio_e55, workpad)
> * parisc
> * powerpc (prep, chrp)
> * x86
> I'm pretty sure that a significant subset of these actually only
> have PCMCIA and not ISA slots, and some others are also candidates
> for removal.
> If we find out which of this list actually still matter to someone
> who is running current kernels on them, we might be able to just
> ask them what cards they own and kill off all the other drivers.
This came up on a recent netdev thread:
I agree that ISA might have some drivers that still matter to
someone. Collecting that data might be hard though. There
is another source of data though -- us folks who remember
the hardware, and remember which ones were widespread and
stable, vs. which ones were twitchy, rare, or poorly supported,
even back in their "time window".
An example: drivers/scsi/wd7000.c -- there isn't a single
runtime fix in the entire current git history. I recall
trying to make one work back in the mid 1990's and eventually
I just replaced it with functional, stable hardware.
I think we can at least start with making a list of some
of the low hanging fruit like this. I say a list, so that
it is clear someone is coordinating it, and we don't suffer
the "gold rush" syndrome I mentioned earlier.
More information about the Ksummit-2012-discuss