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


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

Exactly my point from KS. The big mash-up will not really make much difference
in terms of Makefile clarity or whatever Thomas' point was. Apparently he 
wanted to eliminate a few lines of code from the Makefile and merge
the header files completely? 

Anyways, the end result will be roughly the same as it is now: i386 and x86-64
are shared in not completely obvious ways and if you change one you have to 
test compile the other too.

Same old, same old, as always.

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

In the end it won't make much difference where the files are located
(although I frankly don't see the advantage of this intrusive move).

You always have to at least compile test both if you change one and I doubt 
most  people will be able to avoid this no matter how the Makefile looks
or where the files are. 

Even if everything was merged together and only ifdefs remained that
fundamental fact would not change either.

A few more files could be also definitely shared, no argument. e.g. 
the time subsystem will likely to be shared soon anyways. And probably
a few others. That should be better all done carefully step by step and 
properly reviewed though, not in some kind of brutal "rewrite the world" 
event.

My concern is mostly that he seems to want to merge some things between 32bit 
and  64bit (like the APIC drivers or the crappy i386 maze-of-inlines 
subarchitecture design) which ought not be together. I think I managed to 
keep x86-64 a relatively clean port over-all, but I see this now going down 
the drain :/

-Andi

  parent reply	other threads:[~2007-09-11 20:39 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
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 [this message]
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=200709112138.11247.ak@suse.de \
    --to=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=sam@ravnborg.org \
    --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