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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
