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

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

Or, apparently my BIOS does not give information or whatever.

They are not completely different things. That online document describes
that biosdevname will take predence if installed.

It also, once more, describes that there are different schemes for
hotplug devices (this takes care of Thunderbolt).

Basically the scheme has two dimensions: prefix (en, wl, ..) and the
first viable "address" naming scheme it finds.

Onboard, hotplug, and card devices are apparently separated as best it can.

In my case my onboard NIC ends up in the 3rd scheme.

Maybe you will say that if my BIOS provided adequate information, it
would have become something else and the PCI renumbering wouldn't be an
issue.

But still everything I wrote was about naming (and sequence condensing).

And yes I want my systems by default to make sense (and for everyone
else as well).

>From a user's perspective, my remembrance is that:
- my ethernet devices have always been enpXsY
- my wlan device has been something short but also something long and
  people report long names.

Why not just pioneer a representation scheme where:

- ethernet (wired) onboard and card devices are called ethernetX with
any onboard device taking precedence

- ethernet (hotplug) devices are called eth-hotplug<slot index number>

- wireless do the same: wirelessX and wifi-hotplug<slot index number>

- wired usb: eth-usb<port>-<port> such as "eth-usb1-2"

There can be multiple USB controllers but USB already has a scheme like
that. These controllers I think are already numbered in sequence. I'm
not sure if that is stable, but it is also not very important. Make it
work without requiring the PCI bus number (p0s29 is not going to be very
meaningful).

So you might get:

eth-usb1-4 or eth-usb1.4-1-2 or something of the kind even. Make it pretty.

Maybe those USB numbers are unstable too?

- wireless usb: same thing: wifi-usb<path>

There is no need for condensing usb numbers. Just as with PCIe-hotplug,
you can't really care about any persistence. You can't really care about
pretty names (too much) because it is obvious that "eth0" wouldn't make
much sense for it.

So propose a scheme for:

- ethernet0, wireless0 as condensed numbers
- eth-hotplug0, wifi-hotplug1 as port numbers
- eth-usb1-4-1 as usb path, same for wifi-usb1-4-1

(could also be wifi-usb1-4p12 or wifi-usb14-12 or wifi-usb1-4_1-2 or
wifi-usb1-4p1p2)

And fill in the rest for stuff I haven't mentioned / don't know about.

The ONLY thing that is required is that you are willing to wait a few
seconds before you fix the list in the case of condensed numbers.

That before networking is started, you take the list of "onboard"
(embedded and card slot) devices and condense that.

Meaning, you wait with renaming until you can be reasonably sure that
everything has made itself known.

Maybe that does not theoretically solve every possible "unstableness"
but I'm pretty sure it would solve 99% of issues that people had even if
you cannot guarantee it.


So yes I am concerned with two things:

- pretty names
- condensation of some default devices.

wireless0
wifi-hotplug1
ethernet0
eth-usb1-4u2

these seem reasonably sensible to me.

the onboard-and-pci-card thing guarantees within bounds that no new
devices are going to show up "suddenly" (like with 99% certainty or more)

In statistics this is called a confidence interval. I am pretty sure a
99% confidence interval for pretty much all embedded/pci-card-hardware
being recognised by the kernel drivers falls within 10 seconds, and even
more sure that it is probably going to fall within a second or 3
starting from boot. On my system, other systems may be faster.

"Greg KH is completely correct -- that can totally happen." (with
reference to some networking device taking 2 hours to respond).

I am pretty sure the occurance of that will fall outside of the 99%
confidence.

I mean, am I being thick here?

I think that for pretty much all functional systems you can with 99%
confidence state that these two types of networking hardware are going
to get recognised within 3 seconds if they get recognised at all.

If you do the renaming and condensing after that, you're done.

It will not change hotplug, it does not depend on fixed PCI bus numbers,
it will not change USB, and it will not change any other thing you don't
want it to.

It will just give people pretty names and predictable names and
99.999999% certainty that this will always work for them and anyone.

With the only possibility that it wouldn't work, being the possibility
that a networking device out of temporary failure is going to be
recognised after you fix the list.

Which could mean after networking is started in any case.