The return of devfs [LWN.net]

The return of devfs

Posted May 7, 2009 8:59 UTC (Thu) by nix (subscriber, #2304)
In reply to: The return of devfs by mjthayer
Parent article: The return of devfs

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.

to post comments

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.