On Tue, Jul 11, 2017 at 9:18 AM, Simon McVittie <s...@debian.org> 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
