From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Chris Wright <chrisw@sous-sol.org>,
Rusty Russell <rusty@rustcorp.com.au>,
Glauber de Oliveira Costa <glommer@gmail.com>
Subject: Re: [PATCH 00/18] Make common x86 arch area for i386 and x86_64 - Take 2
Date: Wed, 14 Mar 2007 20:59:16 +0100 [thread overview]
Message-ID: <20070314195916.GA5674@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.64.0703141120530.9690@woody.linux-foundation.org>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > of code. i386 is 87847 lines of code, x86_64 is 40978 lines of code,
> > a total of 128825. That means we move about 10% of the code. Not
> > insignificant but not earth-shattering either. With alot more effort
> > (and testing) we could realistically go up to maybe 20% - but that's
> > still a bit low to spread out all the files, isnt it?
>
> Well, I'd like it to be 100% _eventually_, and just unify the
> architectures.
ok, having a single bi-arch final tree is indeed intriquing and i didnt
realize that you were suggesting that. (I had the impression that
arch/x86/ was more of a 'common library' thing, not a target
architecture. What felt weird to me was having 3 separate hierarchies -
but as long as it's just a temporary state it's OK.)
> We've now done that both for S/390 and POWER, and I think in both
> cases it's been a clear win. So it's not like this is even a radical
> idea.
the x86_64 and i386 trees have diverged quite a bit though, so this will
be a major logistical undertaking. And with Andi opposed to
fundamentally it it also lacks a bit of manpower i guess :-/
> There really is almost nothing in i386 that shouldn't be supported on
> x86-64 too, unless it literally is the actual low-level asm files and
> vm86 mode support (which in turn is best left as just a config option
> that would just *depend* on 32-bit, so even that could sanely be
> represented in a shared tree without any real downside at all).
yeah. But this really scares the sh*t out of me. I already tried to
unify some of the most fragile lowlevel bits recently: for example the
SMP bootup, TSC sync and APIC initialization sequences were totally
different on x86 and x86_64. And those kind of random deviations have
spread all around the tree. But ... my experience has been pretty
positive: touching both codebases at once tends to dust off old code and
tends to fix more bugs. And in the process of doing that we broke
Andrew's laptop only half a dozen times! ;) But .. in the long run, it's
alot easier to think about unified code. 32-bit x86 will certainly stay
with us for at least 10-20 years, and the best model for maintainance is
having one codebase.
Another practical complication is that even for modular stuff, sometimes
x86_64 has the better code, sometimes i386. But ... the more i think
about it the more i like it. -m32 certainly works fine and does the
right thing.
Ingo
next prev parent reply other threads:[~2007-03-14 20:00 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-14 5:08 [PATCH 00/18] Make common x86 arch area for i386 and x86_64 - Take 2 Steven Rostedt
2007-03-14 5:08 ` [PATCH 01/18] toplevel Kconfig changes Steven Rostedt
2007-03-14 5:08 ` [PATCH 02/18] x86 Makefile changes Steven Rostedt
2007-03-14 5:08 ` [PATCH 03/18] acpi Makefile updates Steven Rostedt
2007-03-14 5:08 ` [PATCH 04/18] make the cpu/cpufreq/Makefile Steven Rostedt
2007-03-14 5:08 ` [PATCH 05/18] mv kernel/cpu/cpufreq/p4-clockmod.c Steven Rostedt
2007-03-14 5:08 ` [PATCH 06/18] mv kernel/cpu/cpufreq/speedstep-lib.h Steven Rostedt
2007-03-14 5:08 ` [PATCH 07/18] mv kernel/cpu/cpufreq/speedstep-lib.c Steven Rostedt
2007-03-14 5:08 ` [PATCH 08/18] create x86/kernel/cpu/Makefile Steven Rostedt
2007-03-14 5:08 ` [PATCH 09/18] create x86/kernel/cpu/mcheck/Makefile Steven Rostedt
2007-03-14 5:08 ` [PATCH 10/18] make the kernel Makefile Steven Rostedt
2007-03-14 5:08 ` [PATCH 11/18] rm include pointer to x86_64 early_printk.c Steven Rostedt
2007-03-14 5:08 ` [PATCH 12/18] rm include pointer to x86_64 tsc_sync.c Steven Rostedt
2007-03-14 5:08 ` [PATCH 13/18] create x86/lib/Makefile Steven Rostedt
2007-03-14 5:08 ` [PATCH 14/18] rm include pointer to i386 msr-on-cpu.c file Steven Rostedt
2007-03-14 5:08 ` [PATCH 15/18] create x86/mm/Makefile Steven Rostedt
2007-03-14 5:08 ` [PATCH 16/18] kconfig for oprofile Steven Rostedt
2007-03-14 5:08 ` [PATCH 17/18] create x86/oprofile/Makefile Steven Rostedt
2007-03-14 5:08 ` [PATCH 18/18] Straight file moves Steven Rostedt
2007-03-14 15:44 ` Linus Torvalds
2007-03-14 16:11 ` Steven Rostedt
2007-03-14 8:00 ` [PATCH 00/18] Make common x86 arch area for i386 and x86_64 - Take 2 Jan Engelhardt
2007-03-14 16:52 ` Linus Torvalds
2007-03-14 10:36 ` Andi Kleen
2007-03-14 9:48 ` sujay g
2007-03-14 12:35 ` Steven Rostedt
2007-03-14 13:05 ` Andi Kleen
2007-03-14 13:36 ` Steven Rostedt
2007-03-14 18:47 ` Andi Kleen
2007-03-14 18:57 ` Jeremy Fitzhardinge
2007-03-14 12:53 ` Ingo Molnar
2007-03-14 13:33 ` Steven Rostedt
2007-03-14 13:41 ` Ingo Molnar
2007-03-14 14:46 ` Steven Rostedt
2007-03-14 16:33 ` Jan Engelhardt
2007-03-14 17:39 ` Steven Rostedt
2007-03-14 17:51 ` Linus Torvalds
2007-03-14 16:49 ` Linus Torvalds
2007-03-14 18:15 ` Ingo Molnar
2007-03-15 16:50 ` Nick Piggin
2007-03-15 17:26 ` Andi Kleen
2007-03-14 15:54 ` Linus Torvalds
2007-03-14 18:09 ` Ingo Molnar
2007-03-14 18:27 ` Linus Torvalds
2007-03-14 19:59 ` Ingo Molnar [this message]
2007-03-14 20:07 ` Andi Kleen
2007-03-14 20:19 ` Ingo Molnar
2007-03-14 20:34 ` Andi Kleen
2007-03-14 20:11 ` Ingo Molnar
2007-03-14 20:21 ` Andi Kleen
2007-03-14 21:34 ` Jan Engelhardt
2007-03-15 15:50 ` Martin Bligh
2007-03-15 15:59 ` Linus Torvalds
2007-03-15 16:06 ` Andi Kleen
2007-03-15 16:23 ` Linus Torvalds
2007-03-15 16:47 ` Steven Rostedt
2007-03-15 16:57 ` Steven Rostedt
2007-03-15 17:01 ` Andi Kleen
2007-03-15 17:21 ` Steven Rostedt
2007-03-16 4:28 ` Christoph Lameter
2007-03-16 11:44 ` Andi Kleen
2007-03-16 20:15 ` Christoph Lameter
2007-03-16 20:25 ` Martin Bligh
2007-03-16 20:48 ` Christoph Lameter
2007-03-16 20:53 ` David Miller
2007-03-16 20:56 ` Christoph Lameter
2007-03-16 20:58 ` David Miller
2007-03-16 20:59 ` Martin Bligh
2007-03-16 21:02 ` Christoph Lameter
2007-03-16 21:51 ` Linus Torvalds
2007-03-19 14:27 ` Andy Whitcroft
2007-03-16 20:47 ` David Miller
2007-03-16 20:52 ` Christoph Lameter
2007-03-16 20:55 ` David Miller
2007-03-16 20:59 ` Christoph Lameter
2007-03-16 20:59 ` Dave Hansen
2007-03-18 23:10 ` Linus Torvalds
2007-03-19 11:08 ` Andi Kleen
2007-03-15 20:02 ` Jan Engelhardt
2007-03-14 15:49 ` Linus Torvalds
2007-03-14 18:40 ` Adrian Bunk
2007-03-16 4:07 ` Kasper Sandberg
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=20070314195916.GA5674@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=chrisw@sous-sol.org \
--cc=glommer@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@linux-foundation.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