[systemd-devel] Proposal: Add biosdevname naming scheme to systemd

[Jordan Hargrave]

On Tue, Oct 20, 2015 at 1:15 AM, Andrei Borzenkov <arvidjaar at gmail.com> wrote:
> On Tue, Oct 20, 2015 at 7:46 AM, Jordan Hargrave <jharg93 at gmail.com> wrote:
>> On Mon, Mar 2, 2015 at 1:17 PM, Tom Gundersen <teg at jklm.no> wrote:
>>> Hi Jordan,
>>>
>>> On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave <jharg93 at gmail.com> wrote:
>>>> There are currently two competing naming mechanisms for network cards,
>>>> biosdevname and systemd.  Systemd currently has some limitations on naming
>>>> cards that use network partitioning or support SR-IOV.
>>>
>>> Could you point to an example so we can fix it? I thought all bug
>>> reports had been handled, but maybe I lost track of something.
>>>
>>
>> I have a quad-port NIC:
>> 0000:40:00.0 = PCIE bridge (SMBIOS Slot 2)
>> 0000:41:00.0 = Ethernet Device (port1)
>> 0000:41:00.1 = Ethernet Device (port2)
>> 0000:42:00.0 = Ethernet Device (port3)
>> 0000:42:00.1 = Ethernet Device (port4)
>>
>> biosdevname would name these p2p1, p2p2, p2p3, p2p4 respectively.
>>
>
> How does it determine that 41 and 42 are the same device? I.e. how
> does it differ from real bridge with two independent two-port cards
> behind? Could you explain what information it is using? Is it exported
> in sysfs?
>
> ...

It knows they are on the same slot as the parent device has SMBIOS
Slot#2 (Type 9).  So all child devices of a physical slot are on the
same card.  I'm currently using a patch to systemd that reads SMBIOS
type 9.  There isn't a kernel sysfs variable that displays this.

Systemd naming really is unfriendly to the end user..., something like
p66s0f0 doesn't tell you at all where in the system the device is
located.  Even worse, as the p<X> number is in decimal, where lspci is
in hex.

>>
>> That could be possible. I've tried submitting a patch upstream for
>> kernel but hasn't been accepted yet.  So SMBIOS parsing would have to
>> be part of systemd.
>>
>
> udev is already using SMBIOS type 41 to obtain slot number for
> on-board devices. As long as this information is exported via sysfs
> for other PCI cards it should be straightforward to extend.