[systemd-devel] Network Interface Names: solution for a desktop OS

Xen list at xenhideout.nl
Fri Apr 15 19:06:02 UTC 2016


Andrei Borzenkov schreef op 13-04-16 05:39:
> Yes. And I do not see how all this information is expected to be stuffed
> into 14 characters available for interface name, or even less if we
> account to VLAN numbers.
> 
> I am not aware of any OS that tries to do it. All of them maintain
> persistent association between interface names and hardware
> characteristics; most use physical topology, but this is not really
> mandatory. Interface names themselves are usually allocated on the first
> come first serve basis. This gives reasonable behavior for small systems
> (where existing interface will always get the same name irrespectively
> of how it is connected) and stable names for large systems.
> 
> That is what we used in the past as well in form of udev rules. And any
> answer "but you can easily disable predictable names" is hypocritical
> because the whole infrastructure to maintain such name database was
> ripped out, so anyone who disables predictable names is forced to
> reinvent the wheel and reimplement it. Which by far exceeds what average
> user is capable of. So average user simply has no choice.


What you are saying is that most OSes keep a record on disk of an
association they have chosen at some point in time, right.

And that you can either use physical topology for this, but other device
identification measures are possible too.

----

The thing what I am currently thinking just comes down on three things:

1. an interface name is not the place where a hardware address needs to
   be registered, kept, maintained, or encoded. The name itself must be
   an alias.

2. this alias is the place to find and access the root device, if any
   device is configured with multiple ports or virtual devices/ports,
   that is an addressing following the resolution of the alias, not as
   part of it

3. persistent mapping may be preferable. But if the mapping is going to
   be redone at every boot, at least make it reasonably persistent
   across reboots, but don't expect it to be the holy grail. If people
   need a truly persistent mapping for persistent hardware (addresses)
   they should create it themselves or operating system software should
   cater to its configuration. For instance.

If you cannot give me a default mapping automatically, why not allow me
to generate one easily? Is there a tool that can take the current device
and produce the list I proposed?

Is there anything against me using that list as a persistent mapping I
device myself? Can this be automated?

Is there a way to generate a (udev) config that will bind my network
device (ep3s0, for instance) to eth0 or ethernet0?

Is any of this made easier? Udev rules are persistent mappings, or could be.

Why not have an operating system installer generate this persistent mapping?


Andrei suggests that you can't:

> And any answer "but you can easily disable predictable names" is
> hypocritical because the whole infrastructure to maintain such name
> database was ripped out, so anyone who disables predictable names is
> forced to reinvent the wheel and reimplement it. Which by far exceeds
> what average user is capable of. So average user simply has no choice.



More information about the systemd-devel mailing list