* Steven Rostedt <[EMAIL PROTECTED]> 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
-
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/
