Re: [PATCH 00/18] Make common x86 arch area for i386 and x86_64 - Take 2


* Ingo Molnar <mingo@xxxxxxx> wrote:

Well, I'd like it to be 100% _eventually_, and just unify the
architectures.

ok, having a single bi-arch final tree is indeed intriquing and i didnt
realize that you were suggesting that. [...]

[...] But this really scares the sh*t out of me. [...]

i think the sanest (and pretty much only) way to do it would be to unify
it _now_, in a single atomic step, safely and in a brute-force way:

create arch/x86/

'unify' arch/i386/ and arch/x86_64/ into arch/x86/ by doing a
brute-force prefix solution:

arch/i386/kernel/process.c => arch/x86/kernel/x32_process.c
arch/x86_64/kernel/process.c => arch/x86/kernel/x64_process.c

create bi-arch Makefiles and enable the building of each arch.

obviously, for files that are already totally identical across the two
arches, the x32_foo.c and x64_foo.c can be changed to foo.c, right away.

nothing else would be done in this step. We'd remove arch/i386/ and
arch/x86_64/ after that.

new files for new functionality can only be added if they are bi-arch.

from this first 'brutal', 'flag day' intrusive step on, every further
step would be more finegrained and per-file: an x32_bar.c and x64_bar.c
file gets merged into bar.c. About 80-90% of our .c files have the same
fundamental purpose in both arches, so this setup makes the most sense
to me: first move them 'close' to each other and force them to be part
of the same basic build architecture, then 'unify' them.

this way we'd also obviously see the costs of not having unified files:
we'd have to change both the x32_ and the x64_ file for the same thing -
while when they are unified, only one change is needed. It's easy to
forget that when the arch directories are separate.

also, unifying two files will also be quite gratifying: one of the files
vanishes, making up for a sail-through-lkml review.

also, this way it's harder for the two trees (and the shared tree) to
get out of sync. If we did 3 separate hierarchies we'd have mixed state
pretty quickly.

also, having the x32_ and x64_ prefix is a painful daily reminder for
all of us changing the architecture that 'this stuff needs to be
unified!'.

hm?

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/

Relevant Pages

  • Re: Binqry Tree sort
    ... > choose your interconnects very carefully. ... In addition we have a network as a parallel ... But the processors which I want to use in my bianry tree architecture ...
    (comp.programming)
  • Re: [RFC][PATCH 2/4] RTC: SWARM I2C board initialization
    ... some places in the kernel tree, ... architecture-specific patches go through the relevant architecture tree. ... unlike the rest of the MIPS arch tree these days the Broadcom bits ... cause the i2c bus registration to fail, as the other platforms do not ...
    (Linux-Kernel)
  • Re: Should Xen be a sub-arch or a build option?
    ... would structure the tree were one to import it into CVS. ... if one were to import Xen support into CVS ... separate architecture. ... If it were me, I'd look at having it be a build option, much like PAE ...
    (freebsd-arch)
  • [RFC, Announce] Unified x86 architecture, arch/x86
    ... The topic of sharing more x86 code has been discussed on LKML a number ... development goes on in the new, shared tree. ... be supported in a single architecture tree. ... unification between equals, all legacies and all new code is unified ...
    (Linux-Kernel)