On Tue, 11 Sep 2007, Sam Ravnborg wrote:
>
> From the mails and discussions I expected it be be obvious what was i386
> only, what was shared and what was x86_64 only.
The problem right now is the *reverse* - even though they are in different
subdirectories (and thus *look* like they are all separate), they aren't.
So the merged end result is much better: at a first approximation
everything is shared (largely true), and the ones that aren't shared can
be made more obvious.
> But see following table
>
> Filename i386 x86_64
> acpi.c X X
> common.c X X
> direct.c X X
> early.c X X
> fixup.c X X
> i386.c X X
> init.c X X
> legacy.c X X
> mmconfig-shared.c X X
So sharing is the default, as it should be.
> irq.c X
> k8-bus.c X
> numa.c X
> pcbios.c X
And these are examples of things that likely *should* be shared, and have
nothing what-so-ever to do with 32- vs 64-bit issues. For example, neither
NUMA nor k8 is in *any* way a 32-bit vs 64-bit issue, they are issues with
chips that can be used as either.
> mmconfig_32.c X
> mmconfig_64.c X
And this is obvious, and correct.
> visws.c X
Now, arguably this should be entirely elsewhere (ie in the "mach-visw"
directory).
> In the filename there is NOTHING for most of
> the non-shared code that tell that this file is
> used by only i386 or x86_64.
.. and that's because of historical issues, and has nothing to do with the
merge, and everything to do with all the problems that the merge is
supposed to eventually help us FIX!
> The exception is mmconfig that is prefixed with _32 versus _64.
> But as I have understood the mails floating around using _32,_64
> is a way to say here are a potential candidate for futher merging.
Yes. But so are others.
> If legacy.c numa.c, pcibios.c and visws.c placed in a directory named i386
> then it would be obvious that this is i386 only.
But none of it is "i386 only" and putting it in a directory of its own
would be stupid and wrong. The visws.c thing is platform-specific thing,
and the fact that the platform happens to be 32-bit is totally secondary
to the much bigger issue of the *platform*, so again, it would be totally
wrong to split it up by wordsize.
> I dunno if this will address the concern of Andi about mixing i386 and x86_64
> but to me at least things would be so much more obvious if the original
> relationship are spelled out.
I obviously disagree violently. We should absolutely *not* make any of
this depend on word-size. Quite the reverse!
Linus
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
