linux-kernel - Re: [PATCH 00/18] Make common x86 arch area for i386 and x86_64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070314201156.GA9603@elte.hu>
Date:	Wed, 14 Mar 2007 21:11:56 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Chris Wright <chrisw@...s-sol.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Glauber de Oliveira Costa <glommer@...il.com>
Subject: Re: [PATCH 00/18] Make common x86 arch area for i386 and x86_64 - Take 2

* Ingo Molnar <mingo@...e.hu> wrote:

> > 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. [...]
>
> [...] But this really scares the sh*t out of me. [...]

i think the sanest (and pretty much only) way to do it would be to unify 
it _now_, in a single atomic step, safely and in a brute-force way:

 create arch/x86/

'unify' arch/i386/ and arch/x86_64/ into arch/x86/ by doing a 
brute-force prefix solution:

  arch/i386/kernel/process.c   => arch/x86/kernel/x32_process.c
  arch/x86_64/kernel/process.c => arch/x86/kernel/x64_process.c

create bi-arch Makefiles and enable the building of each arch.

obviously, for files that are already totally identical across the two 
arches, the x32_foo.c and x64_foo.c can be changed to foo.c, right away.

nothing else would be done in this step. We'd remove arch/i386/ and 
arch/x86_64/ after that.

new files for new functionality can only be added if they are bi-arch.

from this first 'brutal', 'flag day' intrusive step on, every further 
step would be more finegrained and per-file: an x32_bar.c and x64_bar.c 
file gets merged into bar.c. About 80-90% of our .c files have the same 
fundamental purpose in both arches, so this setup makes the most sense 
to me: first move them 'close' to each other and force them to be part 
of the same basic build architecture, then 'unify' them.

this way we'd also obviously see the costs of not having unified files: 
we'd have to change both the x32_ and the x64_ file for the same thing - 
while when they are unified, only one change is needed. It's easy to 
forget that when the arch directories are separate.

also, unifying two files will also be quite gratifying: one of the files 
vanishes, making up for a sail-through-lkml review.

also, this way it's harder for the two trees (and the shared tree) to 
get out of sync. If we did 3 separate hierarchies we'd have mixed state 
pretty quickly.

also, having the x32_ and x64_ prefix is a painful daily reminder for 
all of us changing the architecture that 'this stuff needs to be 
unified!'.

hm?

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/