On Sun, 20 Aug 2017 17:18:13 +0200
Adam Borowski <kilobyte@???> wrote:

> On Sun, Aug 20, 2017 at 03:45:08PM +0100, Rowland Penny wrote:
> > On Sun, 20 Aug 2017 16:27:26 +0200
> > Adam Borowski <kilobyte@???> wrote:
> [my snip:]
> > > * any renames to "eth0"/"wlan0" are a losing idea, as a new
> > > interface can appear at any moment, clashing with what you just
> > > tried to rename to. Several approaches to avoid this race have
> > > been tried, none worked reliably. Thus, any sane renaming should
> > > use a new namespace. Of what was proposed, it looks like people
> > > liked "en0"/"wl0" the most (yeah, it's purely an aesthethic
> > > thing). My idea "e0"/"w0" is too short to imply out of context
> > > you're talking about interface names, etc.
>
> > What is the difference between eth0/wlan0 and en0/wl0 or even
> > e0/w0 ? They are just variations on a theme.
>
> You can't safely rename to eth0/wlan0. At bootup, when an interface
> is being cold/hot-plugged, an *udev script is run. When that script
> decides that the interface that it's been called for should be
> "eth1", it is possible (during boot-up, likely) that another
> interface pops up, and the kernel gives it the next name in sequence,
> ie, "eth1". And the result is not pretty.

OK, when you put it like that, I can understand using a different name
space, but remember you are also dealing with human beings so whatever
name is used, it must be meaningful and the systemd ones aren't.

>
> It's a natural thing to favour "eth*", ie, like things used to be in
> the past. Too bad, this fails due to the above race. In theory, the
> obvious thing would be "if rename fails, try again" -- but none of
> implementations so far hasn't done this right. Using your own
> namespace avoids this problem entirely.
>
> > The systemd way of doing things is, in my opinion, stupid and
> > doesn't actually help.
>
> It's main downside is that you never know what interfaces a new
> machine has. Without systemd-udev, you can 100% predict that a
> machine with only one wired interface will have eth0. With systemd
> "predictable" names, you never know. Even worse, that name is not
> predictable over major kernel upgrades, a slight change of qemu's
> command line, etc.

So much for one of systemd's selling points then.

>
> > If you have more than one ethernet (or wireless) device, then yes,
> > they need to be consistently named, but as most people will not be
> > adding (or removing) devices often, could they be issued with a
> > name based on their MAC and store this somewhere and then use this
> > to rename the network devices once they are all up ?
>
> But how can you know they're all up? Even if you disregard hotplug
> (ie, attaching a new (typically USB) network card at runtime), some
> hardware takes a surprisingly long time to get ready. Waiting for
> userspace to upload required firmware (which needs the filesystem to
> be up) means the hardware's initialization only _starts_ at the time
> you'd expect it to be all done.

There has to be a way of finding network devices attached to a computer
at boot and ensuring they are initialised, otherwise nothing is ever
going to work.

>
> Even an answer "I expect as many interfaces as there were last boot"
> won't work if the admin has just installed a shiny new network card.
> And this happens even on regular desktops -- my on-board PHY decided
> to become a nyetwork card a few months ago.

I am not saying that you can expect the same number of network devices
as last time the computer booted, but in the majority of cases where
there are more than one network device, they will always be there.

As far as I am aware, each network device should have a different MAC,
couldn't this be used to identify which device is which ?

Rowland