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  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, 12 Jul 2007 02:37:13 +0200
From:	Andi Kleen <>
To:	Ingo Molnar <>
Cc:	Andi Kleen <>,
	Linus Torvalds <>,
	Thomas Gleixner <>,
	Andrew Morton <>,,
	Arjan van de Ven <>,
	Chris Wright <>
Subject: Re: x86 status was Re: -mm merge plans for 2.6.23

On Thu, Jul 12, 2007 at 02:18:07AM +0200, Ingo Molnar wrote:
> > > i dont think "clean, modern x86 code" will ever happen - x86_64 has 
> > > and is going to have the exact same type of crap. And i'll say a 
> > > weird thing
> > 
> > Yes, but it will be new crap, but no old crap anymore.
> > 
> > If you always pile the new crap on the old crap at some point the 
> > whole thing might fall over. 64bit was intended as a fresh start.
> I think there's no such thing as a fresh start for a diverse 
> architecture - the ia64 failure has proven that. x86_64 CPUs still do 
> A20 emulation today (!). 

x86-64 doesn't care about a lot of x86 baggage and a lot of
things have been even obsoleted in the platform.

In practice the backwards compatibility on x86 isn't that
great either.  For example a significant number of new systems don't 
even work correctly in PIC mode anymore.

> We still have people running industrial boards 
> on real i386 DX CPUs, with the latest upstream kernel. 15 years ago an 

Yes, but those for example would be perfectly happy with an arch/i386
with all APIC and SMP code stripped out.

Only the few people who still run dual P5s might not, but
those could continue using old kernels.

But eventually I think that would be the right clean way: 

arch/i386 stripped down port for truly old systems like the embedded 386
upto 586 or early 686. No SMP or APIC.
arch/x86 supporting 32bit and 64bit for reasonably modern systems.
NUMAQ/Voyager/P5-SMP/visual workstation gone [frankly the user
base of those is too small to justify the code impact]

It's just quite ugly to get there and when you think through it
the actual advantages of such a setup it is likely not enough to 
justify the significant work to make it work.

Also I wouldn't have any idea how to regression test significant
changes to arch/i386 aimed at old systems. e.g. I don't think
the powerpc people actually tried to still support really
old systems where it is hard to do regression tests anymore,
only really supported platforms.

So while such a setup would be quite nice the practical
problems of getting there are nasty. Also I must admit I prefer
hacking on new code instead.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists