Message-Id: <1185005750.4012.100.camel@chaos>
Date:	Sat, 21 Jul 2007 10:15:50 +0200
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andi Kleen <ak@...e.de>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...radead.org>,
	Chris Wright <chrisw@...s-sol.org>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [RFC, Announce] Unified x86 architecture, arch/x86

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

Powered by blists - more mailing lists