[lkml]   [2007]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC, Announce] Unified x86 architecture, arch/x86
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.

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.

> 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

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.

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-07-21 07:41    [W:0.166 / U:1.132 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site