On Sat, 2007-07-21 at 07:37 +0200, Andi Kleen wrote:
> On Saturday 21 July 2007 00:32, Thomas Gleixner wrote:
> > We are pleased to announce a project we've been working on for some
> > time: the unified x86 architecture tree, or "arch/x86" - and we'd like
> > to solicit feedback about it.
>
> Well you know my position on this. I think it's a bad idea because
> it means we can never get rid of any old junk. IMNSHO arch/x86_64
> is significantly cleaner and simpler in many ways than arch/i386 and I would
> like to preserve that. Also in general arch/x86_64 is much easier to hack
> than arch/i386 because it's easier to regression test and in general
> has to care about much less junk. And I don't
> know of any way to ever fix that for i386 besides splitting the old
> stuff off completely.
I disagree of course.
I worked on both trees quite intensive over the last years and I broke
x86_64 more than once when hacking on i386 and vice versa.
Your "junk" argument is nothing else than a strawman which you beat on
every time when this discussion comes up.
> Besides radical file movements like this are bad anyways. They cause
> a big break in patchkits and forward/backwards porting that doesn't
> really help anybody.
Interestingly enough the folks with the big patch kits (Virtualization)
would be quite happy about that move.
> > This causes double maintenance
> > even for functionality that is conceptually the same for the 32-bit and
> > the 64-bit tree. (such as support for standard PC platform architecture
> > devices)
>
> It's not really the same platform: one is PC hardware going back forever
> with zillions of bugs, the other is modern PC platforms which much less
> bugs and quirks
It _IS_ the same platform. x86_64 is PC hardware with zillions of bugs
as well. And it is not modern at all. It is nothing else than a 64 bit
version of the legacy x86.
> To see it otherwise it's more a junkification of arch/x86_64 than
> a cleanup of arch/i386 -- in fact you didn't really clean up arch/i386
> at all.
We went for a 1 : 1 replacement without merging anything which is not
obvious in the first place (identical files and files, which are just
including some other file). That way we were able to do a binary
compatible migration.
The clean up is the next step and there are enough folks out there
willing to help on this.
> > As an initial matter, we made it painstakingly sure that the resulting
> > .o files in a 32-bit build are bit for bit equal.
>
> You got not a single line less code duplication then, so i don't really
> see the point of this.
Really ?
The script detected 15 identical files with a simple cmp.
It also unified another 10 by simply looking at the only line in there
"include <the other arch/file>"
And there is more of that, when you take the time and look closely at
the _32.[ch] _64.[ch] files which are created by the merge.
tglx
-
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/
