Problems in the way of straightforward device naming in operating systems

July 12, 2021

I've recently been writing (again) about Linux network interface names, this time what goes into udev's normal device names. This is a perennial topic in many operating systems; people are forever wanting straightforward and simple names for devices (networks, disk drives, and so on) and forever irritated that operating systems don't seem to be able to deliver this. Unix network device naming makes an illustrative example for everything that adds complexity even without hot-plugged devices.

Once upon a time the name of Unix Ethernet devices was simple; they were called eth0, eth1, eth2, and so on. This is an appealing naming scheme for networks, disk drives, and so on; you number the first Ethernet eth0 and go upward from there. The big problem with this naming scheme is the question of how you decide what is the first Ethernet, and in general how do you create an order for them and then keep it stable.

The minimum requirement for any naming scheme is that if the system is rebooted with no other changes, you get the same device names. In any operating system that probes and registers physical devices in parallel, this means you don't want to make the order be the order in which hardware is detected, because that might vary from reboot to reboot due to races. If one piece of hardware or one device driver is a little faster to respond this time around, you don't want what eth0 is to change. Operating systems could probe and register hardware one at a time, but this is unpopular because it can take a while and slow down reboots. Generally this means that you have to order devices based on either how they're connected to the system or some specific characteristics they have.

(The hardware changing how fast it responds may be unlikely with network interfaces, but consider disk drives.)

The next thing you want for a naming scheme is that existing devices don't have their names changed if you add or remove hardware. If you already have eth0 and eth1 and you add two new network cards (each with one interface), you want those two new interfaces to be eth2 and eth3 (in some order). If you later take out the card that is eth2, most people want eth3 to stay eth3. To make this case more tricky, if the card for eth2 fails and you replace it with an identical new card, most people want the new card's network interface to also be eth2, although it will of course have a different unique Ethernet hardware address.

Historically, some operating systems have attempted to implement this sort of long term stable device naming scheme by maintaining a registry of associations between device names and specific hardware. This creates its own set of problems, because now your replacement eth2 is most likely going to be eth4, but if you reinstall the machine from scratch it will be eth2 again. This leads to the third thing you want in a naming scheme, which is that if two machines have exactly the same hardware, they should have the same device names. Well, you may not want this, but system administrators definitely do.

Most modern general purpose computers use PCIe, even if they're not based on x86 CPUs. PCIe has short identifiers for devices that are stable over simple reboots in the form of PCIe bus addresses, but unfortunately it doesn't have short identifiers that are stable over hardware changes. Adding, removing, or changing PCIe hardware can insert or remove PCIe busses in the system's PCIe topology, which will renumber some other PCIe busses (busses that are enumerated after the new PCIe bus you've added). PCIe can have fully stable identifiers for devices, but they aren't short since you have to embed the entire PCIe path to the device.

It's possible to reduce and postpone these problems by expanding the namespace of device names. For instance, you can make the device names depend on the hardware driver being used, so instead of eth0 and eth1, you have ix0 and bge0. However, this doesn't eliminate the problem, since you can have multiple pieces of hardware that use the same driver (so you have ix0, ix1, and so on). It also makes life inconvenient for people, because now they have to remember what sort of hardware a given system has. A long time ago, Unix disk device names were often dependent on the specific hardware controller being used, but people found that they rather preferred only having to remember and use sda instead of rl0 versus rk0 versus rp0.

(The third problem is that your device names can change if you replace a network card with a different type of network card; you might go from bnx0 to bge0. It might even be from the same vendor. Intel has had several generations of networking chipsets, which are supported by different drivers on Linux. My office machine has two Intel 1G interfaces, one using the igb driver and one using the e1000e driver.)

Comments on this page:

The most complicated setup I had on a non-switch was a notebook with built-in ethernet, built-in wifi and a USB network dongle, and back then these were automatically named eth0, wlan0, and usb0, so that was a non-issue for me. ;)

Some machines here have dual ethernet ports, but they seem to have stable order so I just keep the interfaces as eth0, eth1.

Definitely more predictable than anything new they came up with.

By Opk at 2021-07-13 08:50:13:

With the driver based naming that you get on the BSDs, I really appreciate the fact that for an interface named, e.g. bge0, I know that I can type man bge to get to the relevant documentation.

When kickstarting new Linux systems at work, I constantly need to guess at the name try it and then correct for whatever it has actually been called once I have some error logs. And for some reason, Network Manager likes renaming them to something with a space in the name. I've no idea why but I end up with "System eno2" for one of the interfaces under Network Manager. That's even more annoying than having to remember and type stuff like "enp1s0f0".

Written on 12 July 2021.
« Understanding something about udev's normal network device names on Linux
Some ways to get (or not get) information about system memory ranges on Linux »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jul 12 23:28:24 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.