Re: PCI slots

Re: PCI slots

[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

Re: PCI slots

[Matthew Wilcox]

On Tue, Nov 06, 2007 at 11:45:10AM -0600, Linas Vepstas wrote:
> Hi,
> 
> Cross-posting to the udev mailing list.

I was actually thinking that linux-scsi would be the more appropriate
list for discussing the presentation of scsi bay information.  But maybe
the udev list is the right place to hash this out first.

> 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.

It might be worth also including a link to the original message:

http://marc.info/?l=linux-pci&m\x119432330418980&w=2

and to let the udev people know that we already have a /sys/bus/pci/slots,
but it's only populated for slots which have a hotplug driver currently.
I was assuming that knowledge on the part of linux-pci folks, but the
udev people might not know about it.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

-------------------------------------------------------------------------
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

Re: PCI slots

[Greg KH]

On Tue, Nov 06, 2007 at 11:03:46AM -0700, Matthew Wilcox wrote:
> On Tue, Nov 06, 2007 at 11:45:10AM -0600, Linas Vepstas wrote:
> > Hi,
> > 
> > Cross-posting to the udev mailing list.
> 
> I was actually thinking that linux-scsi would be the more appropriate
> list for discussing the presentation of scsi bay information.  But maybe
> the udev list is the right place to hash this out first.
> 
> > 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.
> 
> It might be worth also including a link to the original message:
> 
> http://marc.info/?l=linux-pci&m\x119432330418980&w=2
> 
> and to let the udev people know that we already have a /sys/bus/pci/slots,
> but it's only populated for slots which have a hotplug driver currently.
> I was assuming that knowledge on the part of linux-pci folks, but the
> udev people might not know about it.

Heh, as the one of the udev "people" is the same person who added that
sysfs file to the tree, I think we might already know about this :)

Anyway, udev deals with device nodes, which pci slots do not really
matter for, so I doubt udev will need to handle anything at all here.

thanks,

greg k-h

-------------------------------------------------------------------------
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