linux-kernel - Re: Genapic cleanup & NUMAQ/es7000 removal

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]

Date:	Thu, 5 Feb 2009 18:29:41 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Tim Pepper <tpepper@...il.com>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org
Subject: Re: Genapic cleanup & NUMAQ/es7000 removal

* Tim Pepper <tpepper@...il.com> wrote:

> On Fri, Jan 30, 2009 at 2:17 AM, Andi Kleen <andi@...stfloor.org> wrote:
> > Just to demonstrate the clean up possibilities by removing es7000
> > and numaq here's a sample patch series. It doesn't actually remove
> > the es7000/numaq code, but just marks them broken and then
> > removes all the hooks only used by them. I'm not actually sure
> > I caught all the now unused hooks, there are probably now more.
> > Also I think there's still some other NUMAQ only code in smpboot.c
> > that could be exercised.
> >
> > This removes 6 hooks and 2 fields out of struct genapic (out of 26
> > hooks, a reduction of ~23%!)
> >
> > The first three patches are independent cleanups that should
> > be applied anyways.
> >
> > This gives a nice generic cleanup:
> 
> These look good to me for inclusion along with the big "x86: unify genapic 
> code, unify subarchitectures, remove old subarchitecture code" series, or 
> as Andi's indicated the initial cleanups themselves if the other big set 
> doesn't make the 2.6.30 for some reason.  For this series:
> 
> Acked-by: Tim Pepper <lnxninja@...ux.vnet.ibm.com>

I'm not going to apply that series for the reasons i outlined in the NUMAQ 
discussion already. The runtime callbacks arent really a maintenance 
problem: most of them are in boot code so it's not a runtime overhead issue.

The build and code readability complications that came from the broken 
subarch design were the real maintenance problem - and i fixed that. If i 
wanted to simply drop these subarchitectures i could have done that via 5 
straightforward patches.

The unified x86 tree and the whole x86 platform is all about being 
compatible. We do drop hardware features occasionally but only when they are 
undeniably not reachable via any Linux user anymore and have been broken and 
unfixed for a long time. We are not there yet.

We could de-quirk the whole x86 code but then there would not be much code 
left :-)

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