linux-kernel - Re: x86: unify genapic code, unify subarchitectures, remove old subarchitecture code

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090129221402.GA1984@elte.hu>
Date:	Thu, 29 Jan 2009 23:14:02 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Tim Pepper <lnxninja@...ux.vnet.ibm.com>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: x86: unify genapic code, unify subarchitectures, remove old
	subarchitecture code

* Tim Pepper <lnxninja@...ux.vnet.ibm.com> wrote:

> The machines (yes plural!) on which we had regular testing happening 
> have been offline for a few months due to some broader dependencies (eg: 
> console server in the old product used an old version of windows that 
> doesn't meet the corporate security standards) and we've just not 
> managed to get past that.  That in turn is in the way of debugging boot 
> issues with newer kernels.  At this point the most passionate 
> Sequent/IBMers caring about the NUMAQ support are resigned to it being a 
> lost cause.
> 
> The main benefit to carrying NUMAQ support along this long was these 
> machines had a knack for triggering real bugs.  But since there's no 
> active bug testing happening on them now and it doesn't look like there 
> will be...

At this point there's no technical need to kill it - it's a zero-overhead 
thing tucked away into a single .c module in arch/x86/kernel/numaq_32.c. I 
even consolidated most of its headers in that file, to reduce its cross 
section.

That was the main point of the restructuring i did - subarchitectures were 
causing ongoing maintenance overhead before. That overhead is practically 
zero now.

So two days ago it might have made some sense to rip out this code - now 
there's no pressing need really. We can remove it in a few years once the 
last beep has been received from those platforms. The numaq code is now 
quite similar to an old driver in drivers/* - there's no real downside 
from having it around.

	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/