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