All of lore.kernel.org
 help / color / mirror / Atom feed
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

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