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: <1189542314.5235.48.camel@chaos>
Date:	Tue, 11 Sep 2007 22:25:14 +0200
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Andi Kleen <ak@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: x86 merge - a little feedback

Sam,

On Tue, 2007-09-11 at 22:12 +0200, Sam Ravnborg wrote:
> Hi Thomas et al.
> 
> After spending several hours fiddeling with and improving
> the current Makefile for x86_64 I decided to take a closer look
> at the x86 merge og i386 and x86_64.
> 
> I took a closer look at x86/pci. There are 16 C files.
> 
> From the mails and discussions I expected it be be
> obvious what was i386 only, what was shared and what was x86_64 only.
> 
> But see following table
> 
> Filename		i386	x86_64
> acpi.c			X	X
> common.c		X	X
> direct.c		X	X
> early.c			X	X
> fixup.c			X	X
> i386.c			X	X
> init.c			X	X
> irq.c			X
> k8-bus.c			X
> legacy.c		X	X
> mmconfig_32.c		X
> mmconfig_64.c			X
> mmconfig-shared.c	X	X
> numa.c			X
> pcbios.c		X
> visws.c			X
> 
> In the filename there is NOTHING for most of
> the non-shared code that tell that this file is
> used by only i386 or x86_64.

True. I tried to unify the Makefile by using 

obj-$(CONFIG_X86_32) += ....
and
obj-$(CONFIG_X86_64) += ....

but I did fail due to link order problems in that code. I had not yet
time to go down and figure that out yet, but it is on my todo list.

> The exception is mmconfig that is prefixed with _32 versus _64.
> But as I have understood the mails floating around using _32,_64
> is a way to say here are a potential candidate for futher merging.

Yes, if it is possible and makes sense.

> In a meged x86 tree it would be very beneficial to either include
> in the filename that a specific file is i386 or x86_64 specific or
> stuff them in a separate subdirectory.
> 
> If legacy.c numa.c, pcibios.c and visws.c placed in a directory named i386
> then it would be obvious that this is i386 only.
> Or they could be named filename_32 (or the uglier filename_i386).
> As it stands out today the filename are kept but thier relationship are lost.

We concentrated first on the move to make it simple and binary
equivalent. The cleanup of code (merging, location, makefile updates)
are definitely on our todo list.

> I dunno if this will address the concern of Andi about mixing i386 and x86_64
> but to me at least things would be so much more obvious if the original
> relationship are spelled out.

Good point.

	tglx


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ