The return of devfs [LWN.net]

The return of devfs

Posted May 7, 2009 8:00 UTC (Thu) by mjthayer (guest, #39183)
Parent article: The return of devfs

I must admit that I wondered at the time that devfs was deprecated what was so important about device node naming policy that it had to be in the hands of the sysadmin. (Yes, I am not an "old *nix hand" as you will have realised). I would have thought that device-related policy is more useful at a higher level. And while I've always admired microkernels, Linux is not one, and devices are handled in the kernel, so it would make sense to have 600 lines of kernel code for handling the device nodes, rather than all the complex user land stuff there is now. (udev basically duplicates information in sysfs anyway - perhaps this code could be made even smaller by just having a /sys/nodes and linking /dev to that...?) I'm not saying that udev wasn't the right answer at the time, but it might be time to re-examine it.

to post comments

The return of devfs

Posted May 7, 2009 8:59 UTC (Thu) by nix (subscriber, #2304) [Link] (13 responses)

Device node naming policy is a curious beast.

In some respects it must be invariant because it is hardwired into
binaries: some names are even in POSIX (/dev/null, /dev/full).
Without /dev/zero nothing will work, because the dynamic linker uses it.
This may as well go into the kernel, because nobody can ever change the
name without breaking things. Changing this sort of name is why devfs's
new /dev layout was so hard to adapt to.

In some respects it must be tunable by the local admin: only the admin
knows what groups and permissions she wants on any device, and only the
admin knows what she wants to name the USB flash disks that people plug
in. (These names are generally provided to automounters, or mounted by
hand, so it doesn't matter that their names are unpredictably set by
humans.)

In some respects, all that matters is that the name is *consistent*: e.g.
local fixed disks, which are often referenced in files such as /etc/fstab.
Much of the policy for that may as well go into the kernel, because nobody
really cares *what* the name is as long as it doesn't change.

The return of devfs

Posted May 7, 2009 9:13 UTC (Thu) by mjthayer (guest, #39183) [Link] (4 responses)

I see the bit about the permissions. But what difference does it make what the device node for a flash drive is called, as long as the name fulfils certain criteria (i.e. well known, reasonably unique to the drive, etc). Policy can be applied to the mount point name :)

The return of devfs

Posted May 7, 2009 9:29 UTC (Thu) by nix (subscriber, #2304) [Link] (3 responses)

Yes indeed: that was covered by my second case. But *not all devices are
like that*.

The return of devfs

Posted May 7, 2009 9:35 UTC (Thu) by mjthayer (guest, #39183) [Link] (2 responses)

But my point is that these days the user of the system will normally not be interacting with the device nodes and their names unless they are doing something relatively close to the hardware, in which case control over name policy may be nice cosmetics but probably not more. In other cases, something will be layered between the device node and the user, and while that something needs to know the name, it doesn't care more than that what it actually is.

The return of devfs

Posted May 7, 2009 10:43 UTC (Thu) by hppnq (guest, #14462) [Link] (1 responses)

But my point is that these days the user of the system will normally not be interacting with the device nodes and their names unless they are doing something relatively close to the hardware

If it's just your own system, then indeed, nobody cares. But think of managing hundreds or thousands of systems and you may see the value of being able to standardize device naming. The precise naming policy is not so interesting, but the fact that there is one that is consistent is really rather important.

The return of devfs

Posted May 7, 2009 12:21 UTC (Thu) by mjthayer (guest, #39183) [Link]

Quite agree, which more or less falls under my second point. Again, that doesn't mean that you have to be able to choose the names yourself, only that you have to be sure they have been well and predictably chosen. Which is a problem that doesn't necessarily have to be solved over again by every administrator.

The return of devfs

Posted May 7, 2009 9:53 UTC (Thu) by epa (subscriber, #39769) [Link] (7 responses)

In some respects, all that matters is that the name is *consistent*: e.g. local fixed disks, which are often referenced in files such as /etc/fstab.

Often nowadays fstab refers to devices by their disk label, because the device names (sda1, sdb1, etc) might jump around depending on what's plugged in where. Which makes you wonder why the disk label names have to be checked in some magic way, rather than just being exported by the kernel under /dev/disklabel/xxx.

The return of devfs

Posted May 7, 2009 22:38 UTC (Thu) by nix (subscriber, #2304) [Link]

Having the kernel check disk labels at the time they probe for the devices
might work, but wouldn't work if the filesystem on the device was modular
and the module wasn't yet loaded.

(Also it's yet *more* nonswappable kernel code for a job very easily done
by userspace.)

The return of devfs

Posted Oct 5, 2009 7:47 UTC (Mon) by cmccabe (guest, #60281) [Link] (5 responses)

> Which makes you wonder why the disk label names have to be checked in some
> magic way, rather than just being exported by the kernel under
> /dev/disklabel/xxx.

If you're running a non-ancient system with udev, you can find all the disks by label under:

/dev/disk/by-label/

Actually, come to think of it, I'm not sure why the LABEL=foo hack was ever implemented. There must be a reason but I don't know it.

Colin

The return of devfs

Posted Oct 6, 2009 0:07 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

Firstly, LABEL= predates udev. Secondly, LABEL= works even before udev has
initialized. Thirdly, it works on systems without udev. (udev and mount
don't yet use the same probing library, but this is changing, I
understand.)

The return of devfs

Posted Oct 18, 2009 22:43 UTC (Sun) by cmccabe (guest, #60281) [Link]

Ah, that makes sense. Thanks.

The return of devfs

Posted Apr 2, 2010 11:15 UTC (Fri) by skitching (guest, #36856) [Link] (2 responses)

Hi nix,

You mention in your comment that "root=LABEL=" work even when there is no udev.

Does this also apply to "root=UUID="?

And would you be able to give me a hint about where to find that code? All the relevant rootfs mounting bits appear to be in init/do_mounts.c, but I can't find anything related to handling LABEL or UUID. Function name_to_dev_t maps things like "root=08:05", "root=0x0805", "root=/dev/sda5" to a (major,minor) but I can't see UUID/LABEL handling anywhere.

Thanks, Simon

The return of devfs

Posted Apr 2, 2010 12:09 UTC (Fri) by hppnq (guest, #14462) [Link]

I'm sure nix will have more useful information, but you could take a look at libblkid in the meantime. This is used by mount to find devices identified by label or uuid (check the util-linux source).

The return of devfs

Posted Apr 3, 2010 0:50 UTC (Sat) by nix (subscriber, #2304) [Link]

I never mentioned root=. For everything *other* than root filesystem
mounting, the code to look at is libblkid, which supports both LABEL= and
UUID=. That's what mount(8) uses.

Raw non-initramfs/initrd kernel root= parameterwise, all that is supported
in /dev/{fake device name}, root={major:minor}, and
root={major*256+minor}. This is of course yet another reason to use an
initramfs, which can easily use normal mount and/or blkid directly to
support whatever permutations of LABEL=, UUID= or whatever you prefer.

The return of devfs

Posted May 7, 2009 9:50 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

Me too. Why is it considered 'policy' (bad! bad!) for the kernel to specify the name of the device file, but perfectly okay (in classical UNIX terms) to have fixed major and minor device numbers? Surely the major and minor numbers are just as much policy as the name. If users really want their own names they can easily say 'ln -s /dev/kernel_name /dev/my_weird_name', just as easily as 'mknod /dev/my_weird_name b major minor'.

The return of devfs

Posted May 8, 2009 16:14 UTC (Fri) by rmini (subscriber, #4991) [Link]

You can't set ownership or permissions with symlinks, where you can with device nodes. That's probably the more important part of policy than symlinks. Additionally, some devices are difficult to name persistently.