Re: PCI slots

[linas@austin.ibm.com (Linas Vepstas)]

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