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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.