How Debian managed the systemd transition [LWN.net]

How Debian managed the systemd transition

Posted Sep 18, 2015 18:13 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
In reply to: How Debian managed the systemd transition by kreijack
Parent article: How Debian managed the systemd transition

> I think that a more reasonable solution is to still provide the ethN interface name as alias of the new name.
Network code doesn't support it and network devices have always been a 'special case' in Linux. Notice how there are no '/dev/ethX' files.

to post comments

How Debian managed the systemd transition

Posted Sep 19, 2015 14:34 UTC (Sat) by cortana (subscriber, #24596) [Link] (3 responses)

I wonder why no one has ever looked into increasing the maximum network interface name length, and adding a new kind of 'n' device node that network interfaces can use, so that they can show up in /dev just like other devices.

Then we could have /dev/net/by-{index,slot,path,mac} symlinks pointing to the original /dev/eth0 and friends. Both the original names and the predictable names would be there for those who use them, and all names would be usable simultaneously.

That way, so you no longer have to worry about a network interface having its name changed from eth0 to enp0s3 when you reboot with a newer version of udev, as happened to me last week.

You would also be able to pick and choose which name you want to use depending on your use case, just as how, with disks, it's sometimes useful to use the symlink in /dev/disk/by-path for a disk that is commonly hot-swapped (such as a backup disk you change every week) but at the same time it is useful to use /dev/disk/by-uuid for a permanently-mounted filesystem, such as / or /home.

How Debian managed the systemd transition

Posted Sep 19, 2015 20:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> I wonder why no one has ever looked into increasing the maximum network interface name length, and adding a new kind of 'n' device node that network interfaces can use, so that they can show up in /dev just like other devices.
As usual - legacy. The interface name is limited by IFNAMSIZ value which is used in multiple contexts, so you can not use long strings like '/dev/ethN' for interface names. And also there are no provisions for multiple interface names in getifaddrs() calls or similar functions.

Adding new functions that work with regular device nodes is certainly possible, but probably nobody cares too much about it.

How Debian managed the systemd transition

Posted Sep 20, 2015 0:02 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

if they can do eth<mac> then /dev/ethN isn't unreasonably long

How Debian managed the systemd transition

Posted Sep 20, 2015 7:37 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

IFNAMSIZ is equal to 16, so you only have 15 letters for the full path.

And the second problem is that you don't actually _need_ your devices to be mounted at '/dev'. A device node can be anywhere on the system.

It doesn't even require anything exotic - a host might simply with to get info about a TAP/TUN device in a container.

The correct way to fix it would be by creating a new API that uses file descriptors instead of interface names.

How Debian managed the systemd transition

Posted Sep 20, 2015 10:29 UTC (Sun) by kreijack (guest, #43513) [Link]

> > I think that a more reasonable solution is to still provide the ethN interface name as alias of the new name.
> Network code doesn't support it and network devices have always been a 'special case' in Linux.
> Notice how there are no '/dev/ethX' files.

May be that *now* doesn't exist a technical solution for doing that. But I don't see any reason which prevent us to implement it.
Let me to rephrase my sentence: my suggestion could be cause of some problem, or today it is impossible because nobody had coded that solution.
The former may/is a stop, the latter could be solved by some hours of coding (and several days of testing :-) )