public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	Andi Kleen <ak@suse.de>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: x86 merge - a little feedback
Date: Tue, 11 Sep 2007 22:12:19 +0200	[thread overview]
Message-ID: <20070911201219.GA9674@uranus.ravnborg.org> (raw)

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.

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.

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.

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.

	Sam

             reply	other threads:[~2007-09-11 20:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-11 20:12 Sam Ravnborg [this message]
2007-09-11 20:25 ` x86 merge - a little feedback Thomas Gleixner
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=20070911201219.GA9674@uranus.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --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