From: Thomas Gleixner <tglx@linutronix.de>
To: Andi Kleen <ak@suse.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
Ingo Molnar <mingo@elte.hu>,
Arjan van de Ven <arjan@infradead.org>,
Chris Wright <chrisw@sous-sol.org>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [RFC, Announce] Unified x86 architecture, arch/x86
Date: Sat, 21 Jul 2007 10:15:50 +0200 [thread overview]
Message-ID: <1185005750.4012.100.camel@chaos> (raw)
In-Reply-To: <200707210737.59552.ak@suse.de>
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
next prev parent reply other threads:[~2007-07-21 8:16 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-20 22:32 [RFC, Announce] Unified x86 architecture, arch/x86 Thomas Gleixner
2007-07-20 22:38 ` Jeff Garzik
2007-07-20 22:40 ` Ingo Molnar
2007-07-20 22:42 ` Jeff Garzik
2007-07-20 22:51 ` Linus Torvalds
2007-07-21 2:56 ` Yinghai Lu
2007-07-20 23:55 ` Alan Cox
2007-07-21 0:02 ` H. Peter Anvin
2007-07-21 22:26 ` Oleg Verych
2007-07-20 23:01 ` Arjan van de Ven
2007-07-20 23:23 ` Steven Rostedt
2007-07-21 2:39 ` Glauber de Oliveira Costa
2007-07-20 23:55 ` Michal Piotrowski
2007-07-21 0:03 ` Ingo Molnar
2007-07-21 0:16 ` Michal Piotrowski
2007-07-21 5:40 ` Andi Kleen
2007-07-21 5:50 ` Steven Rostedt
2007-07-21 6:06 ` Andi Kleen
2007-07-21 7:35 ` Adrian Bunk
2007-07-21 7:42 ` Andi Kleen
2007-07-21 8:01 ` Adrian Bunk
2007-07-21 8:15 ` Thomas Gleixner
2007-07-21 8:32 ` Ingo Molnar
2007-07-27 10:50 ` Pavel Machek
2007-07-27 18:11 ` Chris Wright
2007-07-20 23:55 ` Arnd Bergmann
2007-07-21 1:59 ` Steven Rostedt
2007-07-21 1:01 ` Gabriel C
2007-07-21 5:37 ` Andi Kleen
2007-07-21 5:58 ` Steven Rostedt
2007-07-21 6:09 ` Andi Kleen
2007-07-21 8:15 ` Thomas Gleixner [this message]
2007-07-21 8:28 ` Andi Kleen
2007-07-21 13:28 ` Glauber de Oliveira Costa
2007-07-21 9:02 ` Rusty Russell
2007-07-21 11:34 ` Brian Gerst
2007-07-21 12:30 ` Ingo Molnar
2007-07-21 15:11 ` Arjan van de Ven
2007-07-21 6:37 ` Avi Kivity
2007-07-21 10:37 ` David Woodhouse
2007-07-21 10:56 ` Adrian Bunk
2007-07-21 22:25 ` Matt Mackall
2007-07-21 23:51 ` Chris Wright
2007-07-22 7:50 ` Thomas Gleixner
2007-07-22 12:02 ` Matt Mackall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1185005750.4012.100.camel@chaos \
--to=tglx@linutronix.de \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=chrisw@sous-sol.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox