From: Thomas Gleixner <tglx@linutronix.de>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Ingo Molnar <mingo@elte.hu>, Andi Kleen <ak@suse.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: x86 merge - a little feedback
Date: Tue, 11 Sep 2007 22:25:14 +0200 [thread overview]
Message-ID: <1189542314.5235.48.camel@chaos> (raw)
In-Reply-To: <20070911201219.GA9674@uranus.ravnborg.org>
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
next prev parent reply other threads:[~2007-09-11 20:25 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-11 20:12 x86 merge - a little feedback Sam Ravnborg
2007-09-11 20:25 ` Thomas Gleixner [this message]
2007-09-11 21:24 ` Linus Torvalds
2007-09-11 20:34 ` Adrian Bunk
2007-09-11 21:05 ` Sam Ravnborg
2007-09-11 21:09 ` Adrian Bunk
2007-09-12 9:27 ` Christoph Hellwig
2007-09-12 12:45 ` Lennart Sorensen
2007-09-11 20:38 ` Andi Kleen
2007-09-11 21:14 ` Adrian Bunk
2007-09-11 21:34 ` Andi Kleen
2007-09-11 21:51 ` Linus Torvalds
2007-09-12 18:14 ` Jan Engelhardt
2007-09-11 21:51 ` Adrian Bunk
2007-09-12 0:29 ` Paul Mundt
2007-09-15 10:55 ` Andrew Morton
2007-09-15 9:32 ` Andrew Morton
2007-09-15 18:36 ` Andi Kleen
2007-09-16 5:08 ` Andrew Morton
2007-09-11 21:21 ` Linus Torvalds
2007-09-12 19:09 ` Sam Ravnborg
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=1189542314.5235.48.camel@chaos \
--to=tglx@linutronix.de \
--cc=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sam@ravnborg.org \
--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