public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andi Kleen <andi@firstfloor.org>,
	Linus Torvalds <torvalds@linux-foundation.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 21:34:54 +0100	[thread overview]
Message-ID: <20070314203454.GD376@one.firstfloor.org> (raw)
In-Reply-To: <20070314201944.GA11583@elte.hu>

> the basic dynamics of legacies does not change if we have only 50% of 
> them: right now x86_64 is just growing its own set of legacies, at the 
> same rate as i386 did it 10 years ago. 

Modern system are much more similar to each other than older systems
due to Windows forcing them and they are using much more hardware. 

For example we'll never have the tons of weird APIC errata again old 
platforms had.

And the 64bit APIC code is already much cleaner because of this
and this made new work (like Eric's rework which only happened
partially on i386) much easier.

Also 64bit doesn't support any weirdnesses like visws,voyager
which probably should have been ripped out long ago because
they cause large issues in the code and are practically unused
(I bet both have userbases I can count on my fingers) 

> practice: those legacies will quickly necessiate the _same_ kinds of 
> abstractions that allow the flexible injection of hardware-dependent 
> quirks. In another 5 years the x86_64 tree will end up looking and 

That's not my experience.

> behaving _just like the i386_ tree, the only difference will be less 
> compatibility. (In fact, it will likely look worse because currently our 
> efforts are 50% split between i386 and x86_64, and the random 

That's also not how it works. Typically bug fixes are applied to both.

> Also, 90% of our users are still running 32bit kernels _even on 64-bit 
> capable hardware_, so we might as well prepare ourselves for a really 
> long march towards a pure 64-bit world. (Which will likely never come.)

32bit is not the problem, the problem is old platforms/weird not quite
PC platforms (which don't exist in the 64bit world)/very old CPUs.
32bit has some ugly legacies  (like vm86) but they are handleable.
The old bugs aren't imho.

When a new unified port was done it could be done for modern x86 only,
with arch/i386 kept for the old legacy stuff.
That would be fine for me. The trouble is just that I'm not sure
that distributions would actually ship it e.g. because not supporting
P5s anymore might be still too radical. And if it was not shipped
then it would be useless.

Besides it's would be a lot of work and frankly not very interesting work.

-Andi


  reply	other threads:[~2007-03-14 20:35 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
2007-03-14 20:07             ` Andi Kleen
2007-03-14 20:19               ` Ingo Molnar
2007-03-14 20:34                 ` Andi Kleen [this message]
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=20070314203454.GD376@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=akpm@linux-foundation.org \
    --cc=chrisw@sous-sol.org \
    --cc=glommer@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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