Re: x86 status was Re: -mm merge plans for 2.6.23

[Ingo Molnar]

* Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:

> > The same is true of a lot of the APIC timer code. Sure, that patch 
> > has the actual conversion in it, and you don't have the 
> > cross-architecture issues, but more than 50% of the patch seems to 
> > be just cleanup that is independent of the actual switch-over, no?
> 
> I don't think it's that much cleanup. One of my goals for x86-64 was 
> always to have it support modern x86 only; this means in particularly 
> most of the old bug workaround removed. With the APIC timer merging a 
> lot of that crap gets back in.

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 
now: that is a _blessing_. Why? Because this crap in question originates 
from the _diversity_ of the platform, and that is a much larger asset 
than the cost of the quirks can ever be!

What you suggest does not end up in "clean 64-bit code", it ends up in 
"a bit less crappy 64-bit code", plus a lot of unnecessary duplication 
of effort and duplication of code - which easily introduces more crap 
total than it gets rid of ...

The x86 architecture isnt fully analogous to a random piece of device 
hardware that evolves. It is more of a collector of random pieces of 
hardware that evolve independently, and as such it will always be 
exposed to human messups in a factorized way. "The pristine, clean 
architecture" is an utopia and it will never come until humans design 
hardware.

Under your scheme we'll end up with is two sets of code which share some 
of the workarounds and dont share some others. No, in fact we _already_ 
ended up with two sets of code that is crappy in different ways. We had 
countless cases of bugs fixed in i386 but not fixed in x86_64. (and vice 
versa) Sharing code for similar hardware is almost always good.

I think the PowerPC experience (although it is not a fully equivalent 
case) about them merging their 32-bit and 64-bit architectures was an 
overwhelmingly positive move, and x86 could learn a thing or two from 
that.

The only way to fight crappy hardware is to map it, to understand it and 
to design as cleanly in the presence of it as possible. Having two sets 
of code for the same thing hardly serves that purpose. In fact, having 
_more_ crappy hardware _forces_ us to do a cleaner design (up to a pain 
threshold).

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/