On Jul 11 2017, 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.
I wonder if anyone actually uses /dev/disk/by-path?
> 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".
>
> 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.
Independent of the current discussion: why not? Is there something that
would prevent the kernel from starting to provide network device nodes
in /dev in some future release?
It seems to me that providing a file in /dev and internally mapping this
to the old device name shouldn't be that big a thing...
Curious,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
