Re: x86 merge - a little feedback

[Linus Torvalds]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/