Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262226AbVERRkl (ORCPT ); Wed, 18 May 2005 13:40:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262200AbVERRj2 (ORCPT ); Wed, 18 May 2005 13:39:28 -0400 Received: from graphe.net ([209.204.138.32]:54544 "EHLO graphe.net") by vger.kernel.org with ESMTP id S262196AbVERRjS (ORCPT ); Wed, 18 May 2005 13:39:18 -0400 Date: Wed, 18 May 2005 10:39:11 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@graphe.net To: Matthew Dobson cc: "Martin J. Bligh" , Andrew Morton , linux-kernel Subject: Re: 2.6.12-rc4-mm2 build failure In-Reply-To: <428B7A5F.9090404@us.ibm.com> Message-ID: References: <734820000.1116277209@flay> <428A8697.4010606@us.ibm.com> <428B7A5F.9090404@us.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -5.9 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1737 Lines: 35 On Wed, 18 May 2005, Matthew Dobson wrote: > 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. The topology function in generic may just do nothing if not defined by the arch like pcibus_to_node. If the arch does not define it return indeterminate and make all node specific allocations fall back to unspecific allocation. This works for all arches and preserves the existing behavior. > 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. Its best to have the kernel setup in such a way that functions can be added without having to cause breakage. It is imaginable that someone will add more hardware something to node functions in the near future given that pcibus_to_node is just for pci. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/