linux-kernel - Re: [PATCH 3/3] x86: drop support for 1995 era EISA based platforms

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.11.1501200350230.28301@eddie.linux-mips.org>
Date:	Tue, 20 Jan 2015 04:05:37 +0000 (GMT)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Paul Gortmaker <paul.gortmaker@...driver.com>
cc:	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 3/3] x86: drop support for 1995 era EISA based
 platforms

On Mon, 19 Jan 2015, Paul Gortmaker wrote:

> The Kconfig text says it all, with "The EISA bus saw limited use
> between 1988 and 1995 when it was made obsolete by the PCI bus."
> 
> That means typically 486/586 CPUs in the 33-166MHz range, and
> 8-64MB of installed RAM in typical EISA machines of that era.
> With the additional cost, they were also typically rare, and not
> getting widescale deployment.
> 
> Given that it is 20 years on since its demise, and the above specs
> might seem just barely acceptable for a wireless router today, lets
> stop forcing everyone to build EISA infrastructure and assoc. drivers
> during their routine build coverage testing for no value whatsoever.
> 
> We'd already removed some obsolete 10Mbit EISA network drivers in
> commit bca94cffabf5c9f2399da34eab00bd534bf3735b ("drivers/net: delete
> 8390 based EISA drivers") over two years ago for the same reason.
> 
> If we don't immediately expire EISA completely, we can at least limit
> its impact and support/testing overhead to the arch like alpha and
> parisc that are essentially frozen in time from a hardware perspective.
> 
> Signed-off-by: Paul Gortmaker <paul.gortmaker@...driver.com>
> ---

 Well, I'd like to keep my x86 box up and alive, to support EISA FDDI 
equipment I maintain if nothing else -- which in particular means the 
current head version of Linux, not some ancient branch.

 Is the maintenance overhead for this stuff really that high?  The amount 
of code you're dropping here does not really impress me.  And it's almost 
exclusively APIC stuff that's straightforward and I can probably give it 
some attention too -- as you may have been aware I have some experience in 
this area, especially where older hardware is concerned.  Unfortunately my 
EISA box is UP, so I can't offer run-time validation for APIC/SMP code at 
the moment, but as I say, this is really plain stuff.

 I don't require that everyone around the planet validates EISA support of 
course -- if that is what really concerns you (quite validly, IMHO), then 
how about a configuration option instead to annotate more exotic stuff 
with, so that people who have, say, commercial interest in Linux only, can 
tick it off and care of what brings them income only?

  Maciej
--
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/