Re: [PATCH 0/5][RFC] Physical PCI slot objects

Matthew Wilcox
2007-11-13T21:58:30Z

On Tue, Nov 13, 2007 at 03:41:21PM -0600, Linas Vepstas wrote:
> /sys/bus/pci/slots
> /sys/bus/pci/slots/control
> /sys/bus/pci/slots/control/remove_slot
> /sys/bus/pci/slots/control/add_slot
> /sys/bus/pci/slots/0001:00:02.0
> /sys/bus/pci/slots/0001:00:02.0/phy_location

Ugh. Almost two years ago, paulus promised me he was going to fix the
slot name for rpaphp. Guess he didn't.

This is one of the hateful things about the current design -- hotplug
drivers do too much. Instead of being just the interface between the
Linux PCI code and the hardware, they create sysfs directories, add files,
and generally have far too much freedom.

We have four different schemes currently for naming in slots/,
1. slot number. Used by cpqphp, ibmphp, acpiphp, pciehp, shpc.
2. domain:bus:dev:fn. Used by fakephp.
3a. domain:bus:dev. Used by rpaphp and sgihp.
3b. Except that rpaphp uses phy_location to present the information that
should be in the name and sgihp uses path.

... I've forgotten what cpci uses. And yenta doesn't use it.

How is anyone supposed to write sane managability tools in the presence
of such anarchy?

> ~ # cat /sys/bus/pci/slots/0000:00:02.2/phy_location
> U787A.001.DNZ00Z5-P1-C2

Right. This should look like:

# cat /sys/bus/pci/slots/U787A.001.DNZ00Z5-P1-C2/address
0000:00:02

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