Cc: Linus Torvalds <torvalds@...>, Thomas Gleixner <tglx@...>, Andrew Morton <akpm@...>, <linux-kernel@...>, Arjan van de Ven <arjan@...>, Chris Wright <chrisw@...>
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
-
