Steve Litt <sl...@troubleshooters.com> writes: > On Mon, 28 Sep 2015 15:45:03 +0100 > Rainer Weikusat <rainerweiku...@virginmedia.com> wrote: > >> ... and who wouldn't want his network interface to be named >> "enp0s29u1u2"? After all, anybody unterstands the meaning of eth0 --- >> how terribly boring! > > I don't like it either, but even anti-systemd distros are going for > this Freedesktop BS.
I think you misunderstood the point I was trying to make (possibly somewhat unclearly): The whole point of having 'an operating system' is that it provides an abstract interface userspace software can use to interact with the physical components of a different computer according to the functions they're supposed to be provide, regardless of the way this particular computer happens to be assembled. Considering this, encoding details of the bus layout and current bus configuration in network interface names is just profoundly stupid. Further, the kernel provides an abstract namespace for 'network interfaces' by assigning names composed of a prefix (like 'eth' or 'wlan') to them, followed by a running number so that each interfaces gets its own name. The numbers are assigned in the order in which the corresponding drivers register their interfaces and the driver routines registering these interface are intended to execute in the order the kernel calls them. This order, in turn, depends on the bus layout and configuration but that's something userspace doesn't have to worry about: For as long as the hardware configuration doesn't change, there'll always be a first ethernet interface named eth0 and it will always be the same interface (in case the hardware configuration does change such that the interface numbering changes, that's something the guy who changed it has to sort out, since he alone knows what he was doing and what he meant to accomplish by it). If network drivers are provided as modules which are loaded on demand, the kernel obviously cannot call the driver init routines directly upon encountering some network interface. Instead, it notifies userspace so that a helper application can load the module. The problem with a certain helper application named udev is that it wrecks havoc on the way the abstract interface namespace provided by the kernel is designed to work by not ensuring that driver init routines will be called in the order in which loading the drivers was requested. Someone presumably considers this a feature but assuming that Mr U Dev Is My Dev hadn't figured out how to use locks to serialize tasks which ought to execute serialized by the time the code was written is equally probable (not understanding when locking has to be used is part of "not having figured it out yet"). Hence, this enp0s29u1u2ing is nothing but a workround for a historic design error in udev. > Luckily, the following command is an easy way to see the names of your > network interfaces: > > ip link | grep "^\S" | cut -d " " -f2 The ip command has a -o ('oneline') option intended to provide an output format more easily parsable by other code. In this case, example output could be [rw@doppelsaurus]~#ip -o link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT \ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000\ link/ether a0:d3:c1:41:c6:c5 brd ff:ff:ff:ff:ff:ff 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000\ link/ether 18:cf:5e:37:7b:85 brd ff:ff:ff:ff:ff and it's possible to reduce this to just the names with [rw@doppelsaurus]~#ip -o link | cut -d: -f2 lo eth0 wlan0 (and in a number of other ways but I think that's the simplest). _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng