public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Dobson <colpatch@us.ibm.com>
To: Christoph Lameter <christoph@lameter.com>
Cc: "Martin J. Bligh" <mbligh@mbligh.org>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.12-rc4-mm2 build failure
Date: Wed, 18 May 2005 10:24:47 -0700	[thread overview]
Message-ID: <428B7A5F.9090404@us.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0505171707100.18365@graphe.net>

Christoph Lameter wrote:
> On Tue, 17 May 2005, Matthew Dobson wrote:
> 
> 
>>Not a big fan of this patch.  It's not wrong, per-se, but it just doesn't
>>sit right with me.  asm-generic/topology.h should be a fallback file for
>>the arches that just want some sort of sane UP/SMP defaults.  The better
>>(IMHO) solution is this patch.  Builds fine on PPC64.
> 
> 
> And what happens if yet another function needs to be added for all arches? 
> Then ppc64 will break again and you will fix it again?

I think you explained it well yourself.  If another function needs to be
added for ALL ARCHES, then ALL ARCHES will need to add the function.  In
most cases there is no single function that is both CORRECT and GENERIC
across all arches.  The way that i386, ia64, ppc64, etc. will map PCI Buses
to Nodes (for instance) will NOT be the same.  Anyone who adds a new
topology function has the responsibility of
1) making sure it works for all arches which support topology, or
2) getting the arch maintainers involved and helping them make sure it
works for all arches.

New topology functions don't really get added all that often.  We've got
the basics (CPU, Mem, I/O Buses, Nodes) mapped in various ways, so there
shouldn't be tons of new functions added.  If someone wants to add a new
function, it's their responsibility to make sure that it doesn't break
anyone's arch.

Regardless, I highly doubt Linus or Andrew will pick up a patch for a new
topology function if it breaks some arch.

-Matt

  reply	other threads:[~2005-05-18 17:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-16 21:00 2.6.12-rc4-mm2 build failure Martin J. Bligh
2005-05-16 23:07 ` Christoph Lameter
2005-05-16 23:15   ` Martin J. Bligh
2005-05-17 17:08   ` Martin J. Bligh
2005-05-17 17:09     ` Martin J. Bligh
2005-05-17 17:20       ` Christoph Lameter
2005-05-17 17:34         ` Martin J. Bligh
2005-05-18  0:04   ` Matthew Dobson
2005-05-18  0:08     ` Christoph Lameter
2005-05-18 17:24       ` Matthew Dobson [this message]
2005-05-18 17:39         ` Christoph Lameter
2005-05-19  0:55           ` Matthew Dobson
2005-05-19  3:36             ` [PATCH] fix pcibus_to_node for x86_64 Christoph Lameter
     [not found] <200505162320.j4GNKDLN002527@shell0.pdx.osdl.net>
     [not found] ` <200505170433.59091.adobriyan@gmail.com>
2005-05-17  0:39   ` 2.6.12-rc4-mm2 build failure Christoph Lameter

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=428B7A5F.9090404@us.ibm.com \
    --to=colpatch@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=christoph@lameter.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@mbligh.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