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: <1173883577.31159.50.camel@localhost.localdomain>
Date:	Wed, 14 Mar 2007 10:46:17 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.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

On Wed, 2007-03-14 at 14:41 +0100, Ingo Molnar wrote:

> hm. Do you have any numbers handy - what is the end-result of your 
> unification work, how many lines of code were unified, compared to the 
> total body of code in i386 and x86_64?

Well, I wasn't combining code that wasn't already combined :)

Just moving code that was referenced by another arch to a common
directory that showed the code is shared.

So, I moved a total of 44 files that were shared. Some of these were in
places where a full directory was shared (the mtrr code). And this
doesn't count the Makefiles and Kconfig files that were also modified.

There were only three files with the 
#include "../../<arch>/<path-to-file>" code.
These three where early_printk.c, tsc_sync.c and msr-on-cpu.c.
The rest is referenced by the Makefiles. This still doesn't make it easy
to find functions via TAGS or search scripts.

If you looked at the 18/18 patch, it has a list of the moved files, with
the exception of the speedstep-lib.h, which was moved in it's own file,
and those that referenced that header.

> symbolic links perhaps? In that case i'd also introduce a common naming 
> scheme: x86_early_printk.c - to make sure we know it right away that 
> those files are bi-arch.

Does the Linux code tree already support sym links? IOW, are there
already sym links in the code tree? (/me probably should just look ;)

So should we have an effort to label the shared code that's already
shared.  As Andi stated, he doesn't like "large scale" renaming since
that doesn't "fix a single bug", and will only "just cause pain".
Although I disagree if in the long run it will make it easier to work
with.  Once one knows about the crazy linking going on then it's not
much of a problem, but what about all those that will have to go through
this learning curve.

The problem I have with the current approach is that it just isn't
clean.  Yes it "works", but it still is a hack.  And if I do need to
write code that will be shared among the two archs (still don't know for
sure if this will be the case), I would like to have a clean method in
doing it.  I don't care what the final solution is, as long as it is
clean and not a hack.

-- Steve

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