From mboxrd@z Thu Jan 1 00:00:00 1970 From: linas@austin.ibm.com (Linas Vepstas) Date: Tue, 06 Nov 2007 17:45:10 +0000 Subject: Re: PCI slots Message-Id: <20071106174509.GP4415@austin.ibm.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Hi, Cross-posting to the udev mailing list. On Tue, Nov 06, 2007 at 10:36:32AM -0700, Matthew Wilcox wrote: > On Tue, Nov 06, 2007 at 11:21:17AM -0600, Linas Vepstas wrote: > > I did not see this, but I do welcome the effort. > > It was last January, when I was still at HP. > > > > It has a slot number which is typically written on the outside of > > > the case. > > > > I would encourage calling these things "geographical locations" or > > "geographical location ids" or "location codes" or something like > > that. They need not be just numbers, they may be ascii strings, > > such as "chasis 3 slot 5". For the pseries systems I work with, > > they are the rather opaque strings, such as "U787A.001.DNZ00Z5-P1-C6" > > which tells me that its chasis 1, slot6, and its hot-plugable. > > It's a directory name -- the name in /sys/bus/pci/slots/. It need not > be a number, but it should be something which makes sense to the user > (and it needs to not contain a / or NUL). > > > > One little wrinkle to bear in mind is that PCIe and SHPC slot numbers > > > are only unique to the chassis they are in. To use multiple chassis, > > > the PCI-PCI Bridge spec says that the Chassis Number Register should > > > be consulted. The way that HP chose to make _SUN unique was to multiply > > > the chassis number by 100 and add it to the slot number. It would be > > > convenient if other manufacturers adopted the same policy. > > > > Err ... numbers or strings? > > For those of us constrained by having to use ACPI, numbers. All I'm > saying is that *if* you have a system which uses SHPC/PCIe and ACPI, > it'd make everybody's life easier to adopt the same convention. > > > I hope that there are arch-specific callbacks, allowing arches to > > provide location codes as appropriate. In my case, "firmware" is > > "open firmware", and its neither ACPI or PCIe. > > Not even callbacks. It would be up to the arch to *create* these slots. > You can call them anything you want. > > > FWIW, I should point out that, on our systems, the CPU's and memory > > also have location codes, so that if one has to hot-plug (or cold-plug, > > even) replace a failed cpu book, or memory book, one yanks the right one. > > I think that's outside of this particular scope of work, since you > wouldn't want CPUs and memory showing up in the pci slots directory ;-) > > > I don't know if you want to broaden your horizons to include such > > things, and I'll try to conclude this mail without mentioning scsi > > disk drive slots. > > I think we have a more appropriate mailing list for that ... > but it'd be interesting to create /sys/bus/scsi/slots, wouldn't it? Well, we have the udev mailing list, at linux-hotplug-devel@lists.sourceforge.net I admit I don't quite understand udev. I do note that they have managed to do the things they do without having had to deal with physical location codes just yet. But perhaps they're interested, or have some commentary? I am cross-posting the long unedited message there, to provide some background to the discussion. --linas ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel