[systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Reindl Harald schreef op 13-04-16 02:04:
> 
> 
> Am 13.04.2016 um 00:03 schrieb Xen:
>> Reindl Harald schreef op 12-04-16 21:35:
>>>
>>> Am 12.04.2016 um 21:24 schrieb Xen:
>>>> However currently for me, biosdev renumbers these, while my scheme
>>>> wouldn't
>>>
>>> wow - you even don't realise that "biosdevname" and
>>> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
>>>
>>> are two completly different things
>>
>> I was just curious whether installing biosdevname would change things,
>> but apparently the program doesn't return anything for -i eth0
> 
> oh my god - they are oth *not* supposed to give back eth0 adn you should
> at leats not throwing with words around you which have a specific
> meaning in the topic

Apparently it was due to systemd already doing its thing. If I turn it
off, now biosdevname -i eth0 will return:

p10p1

The all_ethN policy simply returns:

eth0 --- this is apparently a reordered system, but since I have only
one NIC, you won't see anything special. I guess this is the system that
was said to create race conditions.

I don't know why biosdevname is not actually used, even though the
online document says so, by the systemd scheme.

"The all_ethN policy makes a best guess at what the device order should
be, with embedded devices first, PCI cards in ascending slot order, and
ports in  ascending  PCI bus/device/function order breadth-first.
However, this policy does not work if your PCI devices are hot-plugged
or hot-plug‐gable, including the virtual functions on an SR-IOV device.
In a hot-plug scenario, each separate udev instance will be  invoked  in
parallel, while the device tree is still being populated with new
devices.  Each udev instance will see a different PCI tree, and thus
cannot provide con‐sistent enumeration.  Use of this policy should be
limited to only scenarios where all PCI devices are present at boot
(cold-plug)."

Seems close to what I wanted. Seems almost exactly what I wanted. The
"ethernet0" scheme I proposed is also only meant for cold-plug.

So basically, Reindl / Greg, the thing you are criticising is already
implemented and functioning in biosdevname, the program.

So I don't know what you are on about. You say it cannot be done, and it
has already been done.

Apparently you can use it in udev rules you design yourself (I have no
knowhow about that).

biosdevname, according to the web page, has formed the basis for the
current systemd scheme.

But it is also still a program you can use to accomplish the thing I
want, albeit in a limited fashion.

I guess it needed a kernel parameter to be activated.

You are bitching about terminology I use, but everyone already knew what
I was talking about.

Reminds me of this image ;-).

https://s-media-cache-ak0.pinimg.com/736x/09/6a/f8/096af8445c29b9be6c485abecfac7e04.jpg


As well, even though technically the biosdevname and the systemd scheme
are distinct, no one of you or anyone has ever mentioned biosdevname,
all of it has been about the systemd scheme and everyone understood what
I was saying.

So, yes, arguably pretentious. And maybe also purely pedantic here.


> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html

I had already seen both pages, thank you very much.

It did take a while for me to sink in what biosdevname actually was, and
indeed I did not differentiate, but it was also not necessary before
because no one actually refered to the actual "biosdevname".

So thank you for pointing it out, but if it had been relevant, someone
would already have mentioned it.