All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: Adrian Bunk <bunk@kernel.org>, Andi Kleen <ak@suse.de>,
	Sam Ravnborg <sam@ravnborg.org>,
	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: Sat, 15 Sep 2007 22:08:45 -0700	[thread overview]
Message-ID: <20070915220845.89d7445a.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070915183623.GB14501@one.firstfloor.org>

On Sat, 15 Sep 2007 20:36:23 +0200 Andi Kleen <andi@firstfloor.org> wrote:

> On Sat, Sep 15, 2007 at 02:32:58AM -0700, Andrew Morton wrote:
> > On Tue, 11 Sep 2007 23:14:22 +0200 Adrian Bunk <bunk@kernel.org> wrote:
> > 
> > > People do not expect code under arch/i386/ to be used by code under 
> > > arch/x86_64/ and vice versa.
> > 
> > [OT: it drives me batshit that we ended up including stuff in both directions]
> 
> Why? 

It's more complex, obviously.  More surprising.  It used to be the case that
arch/x86^4 files were xx86_64 and arch/i386 files were i386 and possibly
x86_64.  Now it's the case that arch/x86_64 files are x86_64 and maybe i386
and arch/i386 files are i386 and maybe x86_64.  Additional and quite
unnecessary complexity.

I mean, how often do x86_64 changes in your tree break i386?  Once every
3ish weeks would be my guess.  Often this will be because the person making
(and reviewing) the x86_64 change didn't know (or forgot) that the file is
also used by x86_64.

> Anyways, i wouldn't have a problem with putting the already shared
> files into a different directory or move it over to one of the architectures, 
> although I must admit I personally wouldn't see a big benefit from it. But if 
> it gives people a warm fuzzy feeling I'm all for it.

Doing something like that would reduce complexity, reduce surprise and
increase maintainability.  That's more than warm-and-fuzzies.

  reply	other threads:[~2007-09-16  5:10 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
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 [this message]
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=20070915220845.89d7445a.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=ak@suse.de \
    --cc=andi@firstfloor.org \
    --cc=bunk@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.