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

Ingo Molnar
2007-03-14T13:41:30Z

* Steven Rostedt <rostedt@goodmis.org> wrote:

> > i agree. We've recently factored out quite a bit of common code
> > between i386 and x86_64 recently: genirq, gtod/clocksource and
> > clockevents.
>
> But those are things that can mostly be shared across all archs.

yeah.

> > and that's how i think unification of architectures should be done:
> > move code into kernel/* and drivers/*, _not_ into another
> > architecture. That way all architectures benefit.
>
> I'm OK with it, although I did waste a lot of effort making those
> patches (But I speak better in C than in English, or any other verbal
> language, so it wasn't that bad). But if you look at the code that was
> merged, I'm not sure many other archs will benefit. How many archs use
> mtrr's? Perhaps these still can go into the drivers directory with a
> bit of work. Don't know, I'm not that close to that code to be sure,
> and don't have the time to find out ATM.

hm. Do you have any numbers handy - what is the end-result of your
unification work, how many lines of code were unified, compared to the
total body of code in i386 and x86_64?

> But at least there needs to be a more common way to share files
> between the two archs. Having a file with just a single line of:
>
> #include "../../i386/kernel/mycommoncode.c"
>
> is not that elegant. The make files are, perhaps, a bit better.

yeah, that #include file thing for early_printk.c is just gross.

> Another thing that happens a lot with these shared funcs in these
> files, is finding them . Since "make TAGS" doesn't bother to check
> i386 when run with ARCH=x86_64. The first time I searched for
> early_printk while developing i386 took me an hour, since my search
> scripts don't check other archs (I've changed that since). I thought
> that the function was one of these macro created functions, and was
> non-arch specific (didn't look into arch).
>
> So, when creating new shared code, what's the "proper" way?

symbolic links perhaps? In that case i'd also introduce a common naming
scheme: x86_early_printk.c - to make sure we know it right away that
those files are bi-arch.

Ingo