Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Oron Peled]

On Wednesday 23 January 2013 23:49:48 Kay Sievers wrote:
> ...
> We had no better idea really, than to copy the successful model we do
> for disks (and other subsystems) with /dev/disk/by-*/ symlinks. It was
> a well-known scheme, but it was certainly not know for network devices
> so far. So we picked up the basic ideas from biosdevname and combined
> them with the proven scheme we do for all other subsystems in udev.
> This necessarily lead to different names, but from udev's point of
> view they are entirely justified.

The /dev/disk/... is nice because of *two* properties:
 * It indeed provides unique, persistent names
 * But people can still use /dev/sda
   Which is useful in the super-common case of single disk PC

I.e: the predictable names are just aliases for the traditional names.

In another mail on this thread, someone mentioned that this possibility
was looked into, but the related kernel code cannot be easily modified
to support multiple-names per interface.

However, maybe implementing this aliasing in user-space is more tractable?

IMO, my following proposal is only feasible if (and it's a big iff),
the number of system calls and library functions that accept a network
interface name is not large [things like if_nameindex(), the "ifreq" 
ioctl()'s, etc.]

If that's the case, we can map "predictable" names to traditional ones
in user-space, on the entry to said library functions, or entry
to the said glibc syscall wrappers.

Example of a possible mapping scheme:
 * Have udev create a symlink that maps the predictable name into the
   string of the traditional name. E.g:
           /dev/netdev/enp2s0 -> eth0

 * Of course, there's no eth0 file, but nevertheless the symlink can
   contain this string.

 * Now implement ifname_mapto(const char *name, char *new_name) as follows:
   - If there's no /dev/netdev/<name>, use <name> as <new_name> (identity)
   - Otherwise, <new_name> is the result of readlink("/dev/netdev/<name>")

Now if there aren't zillions of functions that process network interface
names, modifying them seems reasonable. The advantage is that
it allows the use the traditional names for the most common cases
(e.g: a laptop with one eth0 and one wlan0) while still providing a
predictable naming to be used when needed.

Now, what do my .signature try to tell me? ;-)

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
... Complex problems have simple, easy to understand wrong answers.