[systemd-devel] network interface renaming via PCI ID w/ systemd-udevd

Filipe Brandenburger filbranden at google.com
Fri Nov 13 10:44:29 PST 2015

On Thu, Nov 12, 2015 at 10:13 AM, Matthew Hall <mhall at mhcomputing.net> wrote:
> On Thu, Nov 12, 2015 at 10:37:56AM +0100, Lennart Poettering wrote:
>> Since time began eth* is where the kernel automatically picked iface
>> names from. If you want to assign your own names go for some other
>> namespace, or be prepared to race against the kernel, and deal with
>> it.
> Again, this logic worked well when the level of dynamism was lower.

I think I see where you're coming from... Some distributions (in my
recollection, RHEL) would use weird tricks to keep interface ordering
stable while still keeping the eth0, eth1, ethX names.

If I recall correctly, RHEL's /etc/init.d/network would try to match
interface names from /etc/sysconfig/networking-scripts/ifcfg-ethX to
the MAC address listed inside that configuration file. If it had to
switch it from, say, eth0 to eth1, it would do weird tricks such as
looking whether eth1 existed already, then rename it to tmp98765 with
a random number, then rename eth0 to eth1. In many cases, something
would go awry and you would end up with an interface named tmp98765.

As you can imagine, this was fraught with problems and race
conditions. It doesn't really work when you're trying to boot with as
much parallelism (which is something we aim for these days) or even
hot plug new interfaces...

> But now the level of dynamism is higher and different principles should apply.

Yes. I'd say that's a good thing.

> You aren't thinking very much about how it will work for newer users.

New users mostly don't care... I really think retraining your fingers
from eth -> enp or whatever you pick, net, lan, wired, etc. is
probably much easier than trying to preserve a relic of a name that
mostly serves no purpose these days... As mentioned, keeping it is not
simple since it's still the dumping ground for the kernel (and that's
unlikely to change), avoiding the race with the kernel is much better
than trying to deal with it, the complexity is just not worth it... I
hope you get to see the light!


More information about the systemd-devel mailing list