Web lists-archives.com

Re: Naming of network devices - how to improve it in buster






On Tue, Jul 11, 2017 at 9:18 AM, Simon McVittie <smcv@xxxxxxxxxx> wrote:
On Tue, 11 Jul 2017 at 13:45:25 +0200, Bjørn Mork wrote:
> I got to ask: Why?  We do not have stable names for e.g. disks.  Why do
> we need it for network devices?

We do have stable names for disks: look in /dev/disk/by-* and you'll see
a bewildering variety of ways to refer to the same disk or partition.

The thing that is different for network devices is that network
devices are not files (device nodes), so udev cannot create a symlink
/dev/network/by-mac/01:23:45:67:89:ab -> /dev/network/eth0 or whatever.
Network devices are (as far as I know) the only class of device managed by
udev that is not backed by a device node, which means udev cannot provide
multiple equivalent names for the same device, and is forced to choose
exactly one of those names, and rename the device if the chosen name
is not the kernel-generated one. That is why naming network devices is,
and has always been, more controversial than naming disks: they are the
one device class in Linux that violates the Unix design rule-of-thumb
"everything is a file".

Is there any (technical) reason why there isn't a kernel mechanism for an "alias" for interfaces that is roughly equivalent to symlinks for files?
 
If network devices were files, udev wouldn't have a configurable
NamePolicy to rename them: it would just provide symlinks for all the
possible naming policies, and let the sysadmin use any, all or none of
those names when configuring tools like ifupdown. Unfortunately, that
isn't possible.

Relatedly, network device name lengths are limited to the length of some
arbitrarily-sized struct field in the kernel ABI,

Feature request to bump the size of of interface names struct? Any reason to not do so?

I know that kernel solutions to our problems isn't a quick fix, but it seems that having interface aliases would allow both camps to be happy.

Sorry if the answers to these questions is obvious.

-m