Date:	Sat, 21 Jul 2007 01:58:16 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Andi Kleen <ak@...e.de>
cc:	Thomas Gleixner <tglx@...utronix.de>,
	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>
Subject: Re: [RFC, Announce] Unified x86 architecture, arch/x86


On Sat, 21 Jul 2007, 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 have to say honestly that it is much easier to work in the i386 arch
directories than the x86_64. But that may be my own feelings.  You seem to
have a nice style that you like and think that it is cleaner. But it
doesn't really seem much cleaner to me. Somethings I like better with the
x86_64 code, and there's somethings I like better with the i386 code. But
from a comfort level, I have to go with worknig with the i386 code.


>
> 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.

I think it helps a lot of people. Especially those that are trying to add
things to _both_ i386 and x86_64.

>
> > 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)

Not sure what you mean here?  I would think that we have this "double
maintence" anyway.  Fixes that are done in x86_64 probably should also be
done in i386.  Why have it in two places?

>
> 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

hehe, I'm seeing a bunch of bugs and quirks appear.  It's just that
x86_64 isn't as old as i386 to have as many of them. But give it time.

>
> 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.

That was not the point of this patch. This patch was to unify the two so
that we can get started on the unification.

>
> > How did we do it?
> > -----------------
> >
> > 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.
>

Did you read what tglx wrote?  The point of this patch was to keep
everything the _same_.  The fact that not a single line less code
duplication is a feature.  A great starting point where we can easily
trace things back to the current arch separation, as well as move forward
in merging the two.

-- Steve

-
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