Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263205AbTFKQsJ (ORCPT ); Wed, 11 Jun 2003 12:48:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263212AbTFKQsJ (ORCPT ); Wed, 11 Jun 2003 12:48:09 -0400 Received: from air-2.osdl.org ([65.172.181.6]:12014 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S263205AbTFKQsE (ORCPT ); Wed, 11 Jun 2003 12:48:04 -0400 Date: Wed, 11 Jun 2003 10:03:26 -0700 (PDT) From: Patrick Mochel X-X-Sender: mochel@cherise To: Matthew Wilcox cc: Benjamin Herrenschmidt , linux-kernel mailing list Subject: Re: pci_domain_nr vs. /sys/devices In-Reply-To: <20030611144801.GZ28581@parcelfarce.linux.theplanet.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2535 Lines: 60 > > /sys/devices/pci-domainN/pciN/* > > > > So we can pave the way for when we'll stop play bus number tricks and > > actually have overlapping PCI bus numbers between domains. (I don't plan > > to do that immediately because that would break userland & /proc/bus/pci > > backward compatiblity) > > > > What do you think ? > > I don't think sysfs works like that (please correct me if I've > misunderstood, mochel..) We can do that, in two different ways. As PCI domains are discovered, devices or kobjects can be registered that represent their existence. Depending on what their parent is, they can be added anywhere into the hierarchy. It might be good to do this anyway, since it will give us the ability to keep a list of all PCI domains in the system, assuming that's desired. :) > Look in /sys/bus/pci/devices/ There you have all the PCI devices > lumped together in one place, and we obviously need the domain number > in the name. I don't know where the 0 on the end of /sys/devices/pci0/ > comes from, but if we could, I wouldn't say no to: > > /sys/devices/pciDDDD/DDDD:BB:SS.F > or > /sys/devices/pciDDDD:BB/DDDD:BB:SS.F > (Domain,Bus,Slot,Func) We could do that (as well as what is described above). However, it's important to note that this exposes a limitation of the driver model. We have a flat name space in /sys/bus//devices/, which is very handy, and nearly free, since each bus maintains a list of all devices anyway. However, since it's a flat listing, the names must be unique across all instances of that bus. Fine, but the names are currently taken directly from dev->bus_id, meaning that the local directories for the devices must also be unique across the entire bus namespace. This is certainly not true, and something that Linus has complained about before. The names in the local directories only need to be unique in the local namespace. Unfortunately, the symlinks are created in the core, and the core doesn't know about bus/device organization. A possilbe solution would be to represent bus instances in the core, and have the symlink names created from a concatenation of the bus name (e.g. DD:BB) and the local device ID (SS.F). This would reduce pressure on bus_id size, and make things easier to read.. -pat - 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/