* Andi Kleen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
