On Tue, Apr 12, 2016 at 5:39 PM, Xen <[email protected]> wrote: > 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 > [email protected] > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
I am the primary developer of biosdevname. I've been wanting this naming functionality built into systemd or even the OS itself. Primarily I am interested in servers with multiple physical and virtual NICs but getting it working on desktops would be a bonus as well. The problem lies in the mapping itself. Network devices can be on a single, dual, or even quad-port cards. Each one of these ports can be 'virtualized' through SR-IOV or NIC partitioning, one physical card can potentially have hundreds of virtual NICs. Other cards implement multiple network interfaces for a single PCI bus:dev:func pair. SMBIOS table has a mapping from slot number to PCI device, this can be used to determine the physical slot number of a network card (and its ports). So there are at least 4 variables that you must keep track of, for add-in cards PCI slot # NIC physical port # (for multi-port cards) NIC device ID (Each physical port can implement multiple network devices) see mlx4 driver or i. NIC partition number (each device can then have multiple partitions/virtual devices) See. SR-IOV or Dell NPAR (network partitioning) For embedded devices (onboard), PCI slot # is replaced by instance number. This is also available through SMBIOS. _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
