On Mar 10, 2019, at 15:33, Gert Doering <[email protected]> wrote: > > Hi, > > On Sun, Mar 10, 2019 at 12:14:54PM -0700, Brian Buhrow wrote: >> hello. I'm not saying anything that anyone here doesn't already know, >> but I'll add that Linux seems to have taken the position that all ethernet >> interfaces should be called eth0, eth1, etc. > > This argument surprises me a bit, as Linux has moved *away* from doing > exactly this a few years ago...
Depending on who you ask, this was either poorly received by the community or “has mixed reviews.” I’ve yet to meet someone who thought it was the best thing ever. That said, when I worked more with NetBSD I had little difficulties working with igb0, and the like. Perhaps because NetBSD feels like I’m working closer to the hardware than Linux, it felt more natural to specify the driver as part of the network device name. Or maybe because I was using NetBSD before I was using Linux, it was just how things worked. When I did start using Linux circa 2000, the “a NIC is a NIC” naming abstraction made a lot of sense. (Yes, I know “a NIC is a NIC” is too facile when you get to the nitty gritty details. There are different features and status exposed via different drivers, depending on the capabilities of the chip — checksum offloading, max frame size, etc — all handled via the driver settings and ioctl. But, for the basics and simply getting the name of the device, the abstraction works well.) > Personally, I'm a bit torn on what is "the best" thing. > > On a system that only has one ethernet card, it's highly annoying > that I have to figure out if this is a "em0" or "igb0" - or an > "eno1" vs. "enp0s25" (both "onboard ethernet 0", but BIOS tables > leading udev to believing the second one isn't). So "eth0, always" > would be very convenient. Or possibly "eth0" for "wired ethernet" > and "wifi0" for wireless - as that's a common scenario. > > For a system with multiple ethernet cards (server with frontend/backend > networks, or firewals, or routers) naming *stability* is a must - having > "em0" and "em1" swap their numbers at upgrading is as disruptive as > "eth0 and eth1 get swapped because one card had to be changed and the > other driver loads first". So here, something based on bus numbering > might be best - stability trumping convenience... This is something I thought was solved *years ago* in the Linux world, and I don’t understand why udev/systemd had to break it. The first time a system boots, the kernel assigned network cards in the order discovered eth0, eth1…ethX, and recorded the device ID to a MAC address mapping in a udev rule. On subsequent boots, the kernel through the udev rules would retain the same device IDs, even if the kernel discovered them in a different order. If a card is replaced, then the new one would get the next ID by default. If an admin wants a certain order, the rules can be changed. In my experience, it worked fine for the simple case of desktops and laptops with one NIC, it provided reasonable defaults and stability in multi-NIC servers, and allowed for arbitrarily complex situations. It’s only in the infrequent case of a replacement NIC that would force an admin to find and update the udev rules (he’s in there already updating the hardware!), which IMHO, falls under Works As Intended. Splitting eth0 vs wifi0 makes sense to me, as the inherent nature of the devices are fundamentally different. jf -- John Franklin [email protected]
smime.p7s
Description: S/MIME cryptographic signature
