Please add support for /sys/bus/pci/slots

[filbranden]

I'm trying to use umockdev-run to add a regression test to systemd and prevent interface naming from breaking again.

So I got a umockdev-record of an interface for which we'd like to keep the name...

But the code that checks for the name enumerates the directories under /sys/bus/pci/slots and looks for one that matches the PCI address.

Any chance you could add support for /sys/bus/pci/slots in umockdev? I'm happy to contribute a patch but I would need some pointers...

For more details, see systemd/systemd#8458 (comment)

Thanks!
Filipe

[filbranden]

@martinpitt Any idea if such a thing is possible?

I'm happy to contribute code, but I wanted to have your take on how to capture this/store it/mock it later... Thanks!

[martinpitt]

My own devices don't have anything in /sys/bus/pci/slots, but the "barriere.debian.org" porter box has.

umockdev-record --all only enumerates everything in /sys/devices/, as there is way too much criss-cross symlinking and stuff which isn't relevant for devices in the other dirs. However, I can't seem to find any link from e. g. /sys/devices/pci0000:00/0000:00:06.0/virtio3/net/eth0 to the slots dir (ls -lR /sys/devices | grep slots is empty). Conversely, it seems that a slot object also doesn't link to /sys/devices in any way. All slot objects look pretty well the same at least on that box:

-r--r--r-- 1 root root 4096 Aug 18 19:32 adapter
-r--r--r-- 1 root root 4096 Aug 18 19:32 address
-rw-r--r-- 1 root root 4096 Aug 18 19:32 attention
-r--r--r-- 1 root root 4096 Aug 18 19:32 cur_bus_speed
-r--r--r-- 1 root root 4096 Aug 18 19:32 latch
-r--r--r-- 1 root root 4096 Aug 18 19:32 max_bus_speed
lrwxrwxrwx 1 root root    0 Aug 18 19:32 module -> ../../../../module/acpiphp
-rw-r--r-- 1 root root 4096 Aug 18 19:32 power

/sys/bus/pci/slots/7$ grep -r . 
latch:1
power:0
adapter:0
grep: attention: Invalid argument
cur_bus_speed:Unknown
max_bus_speed:Unknown
address:0000:00:07

The address attribute is the only promising one, but this doesn't exist anywhere either (find /sys -name 0000:00:07* is empty).

So umockdev-record --all can certainly be taught to enumerate and record the entire /sys/bus/pci/slots`, but it seems awfully disconnected to /sys/devices/. Thus trying to capture a single given device, like you did in that systemd issue, won't catch the corresponding PCI slot object.

I'm trying to understand dev_pci_slot() in src/udev/udev-builtin-net_id.c and try to follow what strace udevadm test-builtin net_id /sys/class/net/eth0 shows: it's iterating through all slot objects and comparing address. I think it's somehow getting it from /sys/devices/pci0000:00/0000:00:06.0/config , but first this is binary gibberish, and second it is a grand-grandparent device of the one that I'm actually looking at (/sys/devices/pci0000:00/0000:00:06.0/virtio3/net/eth0). Do you happen to know how to usefully and robustly connect these?

[filbranden]

Hi @martinpitt, sorry for taking this long to get back to you on this.

So /sys/bus/pci/slots enumerates the "hotplug" slots.

I agree it's pretty disconnected from /sys/devices but it seems that's how it works...

The field that is interesting there is stored in the address pseudo-file, I think at time of recording umockdev should probably traverse the /sys/bus/pci/slots tree and create a mapping from address to slot number (in the case of your machine, 0000:00:07 -> 7).

Then, while enumerating the devices, you use the 0000:00:06.0 address (which you call "grand-grandparent", systemd/udev seem to call this "sysname") and see if it "startswith" one of the slot addresses (in this case, no.)

From the kernel source code for PCI slots, it looks like a shorter format is possible, such as 0000:00 only, though not sure any of those are actually relevant or not... In any case, systemd seems to use the "startswith" logic, so maybe assigning devices to addresses using that logic might be fine.

I imagine in your machine "barriere" you're not connecting eth0 to a slot because eth0 is not a hotplug PCI device! If using systemd/udev names for the interfaces, they would become "ensX" or "wlsX". Unfortunately, I also don't have any devices which match that...

At mocking time, I guess you'd override /sys/bus/pci/slots the same as you mock parts of /sys/devices...

I'm actually happy to contribute code to implement this, but I'm wondering how you'd think this information should be represented...

Something like this perhaps?

P: /slots/7
A: address=0000:00:07

[filbranden]

Actually, I just found a VM where I have an ens33 network adapter!

$ udevadm info /sys/class/net/ens33
P: /devices/pci0000:00/0000:00:11.0/0000:02:01.0/net/ens33
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:11.0/0000:02:01.0/net/ens33
E: INTERFACE=ens33
E: IFINDEX=2
E: SUBSYSTEM=net
E: USEC_INITIALIZED=15902897
E: ID_NET_NAME_MAC=enx000c29d21e2e
E: ID_OUI_FROM_DATABASE=VMware, Inc.
E: ID_NET_NAME_PATH=enp2s1
E: ID_NET_NAME_SLOT=ens33
E: ID_BUS=pci
E: ID_VENDOR_ID=0x8086
E: ID_MODEL_ID=0x100f
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: ID_MODEL_FROM_DATABASE=82545EM Gigabit Ethernet Controller (Copper) (PRO/1000 MT Single Port Adapter)
E: ID_PATH=pci-0000:02:01.0
E: ID_PATH_TAG=pci-0000_02_01_0
E: ID_NET_DRIVER=e1000
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: ID_NET_NAME=ens33
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/ens33 /sys/subsystem/net/devices/ens33
E: TAGS=:systemd:

And:

$ cat /sys/bus/pci/slots/33/address 
0000:02:01

So I do have a machine where I can test such a change...