ok, having a single bi-arch final tree is indeed intriquing and i didnt
realize that you were suggesting that. (I had the impression that
arch/x86/ was more of a 'common library' thing, not a target
architecture. What felt weird to me was having 3 separate hierarchies -
but as long as it's just a temporary state it's OK.)
the x86_64 and i386 trees have diverged quite a bit though, so this will
be a major logistical undertaking. And with Andi opposed to
fundamentally it it also lacks a bit of manpower i guess :-/
yeah. But this really scares the sh*t out of me. I already tried to
unify some of the most fragile lowlevel bits recently: for example the
SMP bootup, TSC sync and APIC initialization sequences were totally
different on x86 and x86_64. And those kind of random deviations have
spread all around the tree. But ... my experience has been pretty
positive: touching both codebases at once tends to dust off old code and
tends to fix more bugs. And in the process of doing that we broke
Andrew's laptop only half a dozen times! ;) But .. in the long run, it's
alot easier to think about unified code. 32-bit x86 will certainly stay
with us for at least 10-20 years, and the best model for maintainance is
having one codebase.
Another practical complication is that even for modular stuff, sometimes
x86_64 has the better code, sometimes i386. But ... the more i think
about it the more i like it. -m32 certainly works fine and does the
right thing.
Ingo
-
