Re: [PATCH 0/1] Use of /sys/bus/pci/devices/…/index for non-SMBIOS platforms

Niklas Schnelle
2021-04-13T06:58:00Z

On Tue, 2021-04-13 at 08:39 +0300, Leon Romanovsky wrote:
> On Mon, Apr 12, 2021 at 03:59:04PM +0200, Niklas Schnelle wrote:
> > Hi Narendra, Hi All,
> >
> > According to Documentation/ABI/testing/sysfs-bus-pci you are responsible
> > for the index device attribute that is used by systemd to create network
> > interface names.
> >
> > Now we would like to reuse this attribute for firmware provided PCI
> > device index numbers on the s390 architecture which doesn't have
> > SMBIOS/DMI nor ACPI. All code changes are within our architecture
> > specific code but I'd like to get some Acks for this reuse. I've sent an
> > RFC version of this patch on 15th of March with the subject:
> >
> > s390/pci: expose a PCI device's UID as its index
> >
> > but got no response. Would it be okay to re-use this attribute for
> > essentially the same purpose but with index numbers provided by
> > a different platform mechanism? I think this would be cleaner than
> > further proliferation of /sys/bus/pci/devices/<dev>/xyz_index
> > attributes and allows re-use of the existing userspace infrastructure.
>
> I'm missing an explanation that this change is safe for systemd and
> they don't have some hard-coded assumption about the meaning of existing
> index on s390.
>
> Thanks

Sure, good point. So first off yes this change does create new index
based names also on existing systemd versions, this is known and
intended and we'll certainly closely collaborate with any distributions
wishing to backport this change.

As for being otherwise safe or having unintended consequences, Viktor
(see R-b) and I recently got the following PR merged in that exact area
of systemd to fix how hotplug slot derived interface names are
generated:
https://github.com/systemd/systemd/pull/19017
In working on that we did also analyse the use of the index attribute
for hidden assumptions and tested with this attribute added. Arguably,
as the nature of that PR shows we haven't had a perfect track record of
keeping this monitored but will in the future as PCI based NICs become
increasingly important for our platform. We also have special NIC
naming logic in the same area for our channel based platform specific
NICs which was also contributed by Viktor.

Thanks,
Niklas