Steve Litt <slitt@???> writes:
> On Mon, 28 Sep 2015 15:45:03 +0100
> Rainer Weikusat <rainerweikusat@???> 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).