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

[Xen]

Just want to summarize here very shortly.


If you turn the hotplug naming scheme into something more attractive.

If you turn the USB naming scheme into something more attractive.

If you accept like a 99.9% confidence interval for waiting until
hardware has shown itself, then taking the (embedded + pci bus) numbers
and condensing that into a sequential list for ethernet and wireless

And if you deal with any other naming scheme there might be.

Then it would solve the utmost total majority of instability issues in
the kernel loading the driver for multiple NICs in quick succession
(this whole issue was mostly about very short intervals I believe) even
if you don't have a 100.00000% guarantee (but you would have a rounded
100% guarantee) particularly if you take into account that
networking+firewall+routing should perhaps not start for a production
system that is very important if not all networking devices for it are
present.

If you are going to start routing and firewalling on non-present
networking devices, you have a problem anyway and the current
"PredictableNetworkInterfaceNames" is not going to solve that.

Then you will have ethernet0 and wireless0 names for the majority (vast
majority) of consumer devices out there.

You will have an almost 100.000% guarantee that an ordinary user with 2
ethernet NICs (like a motherboard with 2 ports) will never ever
experience NIC swapping (eth0 becoming eth1 and vice versa).

You will not see a difference for USB and hotplug because you only
prettify the names, compared to the current system.

The statistical likelihood of this ever going wrong for those 2 NICs is
just very very very very small. I don't care what you say about NICs
showing up 2 hours after the system is booted. If you have a system that
has to wait 2 hours for a relevant or essential NIC, it is going to be
nonfunctional anyway.

If you feel I'm being thick, please say so. I feel I am (but do explain
;-)).

I just don't see how this is going to turn into any problem ever for
anyone. If you do the renaming prior to starting networking, it is
nearly impossible EVER that this will impact real people in a real way.

Maybe that is not acceptable. From my point of view currently with the
knowledge I have, it would work out fine and "waiting for devices to be
present before you act on it" seems like a very nice thing to do anyway.
It feels nice to me.

It is only relevant for networking setups and if both devices you need
are not present (or even more) you should not act on it anyway and the
system should fail. Or you should have a provision that you are alerted
of networking hardware not having come online.

There is not really any scenario where this condensing of enp3s0 names
is going to cause a problem.

And if it does, reboot you know ;-). But it is not going to happen.
Consumer systems usually have one NIC (eth). Routers running systemd
need to guarantee that both needed devices (or more) are present before
starting networking. I bet it is not a problem for them to depend on
fixed bus names, especially if they are embedded systems. But hardware
failure would usually disrupt functioning anyway.

And you could turn that system off if you wanted. It doesn't have to be
the same for everyone, as long as it is convenient and usable for the
majority. Right?

All you need to do is wait a few seconds before you start renaming or
wait on some defined trigger.