Linux: devfs, devtmpfs and udev

Basics

Devtmpfs

Devtmpfs lets the kernel create a tmpfs very early at kernel
initialization, before any driver core device is registered. Every
device with a major/minor will have a device node created in this
tmpfs instance. After the rootfs is mounted by the kernel, the
populated tmpfs is mounted at /dev. In initramfs, it can be moved
to the manually mounted root filesystem before /sbin/init is
executed.

The tmpfs instance can be changed and altered by userspace at any time,
and in any way needed - just like today's udev-mounted tmpfs. Unmodified
udev versions will run just fine on top of it, and will recognize an
already existing kernel-created device node and use it.
The default node permissions are root:root 0600. Only if none of these
values have been changed by userspace, the driver core will remove the
device node when the device goes away. If the device node was altered
by udev, by applying the appropriate permissions and ownership, it will
need to be removed by udev - just as it usually works today.

This makes init=/bin/sh work without any further userspace support.
/dev will be fully populated and dynamic, and always reflect the current
device state of the kernel. Especially in the face of the already
implemented dynamic device numbers for block devices, this can be very
helpful in a rescue situation, where static devices nodes no longer
work.
Custom, embedded-like systems should be able to use this as a dynamic
/dev directory without any need for aditional userspace tools.

With the kernel populated /dev, existing initramfs or kernel-mount
bootup logic can be optimized to be more efficient, and not to require a
full coldplug run, which is currently needed to bootstrap the inital
/dev directory content, before continuing bringing up the rest of
the system. There will be no missed events to replay, because /dev is
available before the first kernel device is registered with the core.
A coldplug run can take, depending on the speed of the system and the
amount of devices which need to be handled, from one to several seconds.

 

udev

Unlike traditional Unix systems, where the device nodes in the /dev directory have been a static set of files, the Linux udev device manager dynamically provides only the nodes for the devices actually present on a system. Although devfs used to provide similar functionality, advocates of udev cited a number of reasons^[2] for preferring its implementation over devfs:

• udev supports persistent device naming, which does not depend on, for example, the order in which the devices are plugged into the system. The default udev setup provides persistent names for storage devices. Any hard disk is recognized by its unique filesystem id, the name of the disk and the physical location on the hardware it is connected to.
• udev executes entirely in user space, as opposed to devfs' kernel space. One consequence is that udev moved the naming policy out of the kernel and can run arbitrary programs to compose a name for the device from the device's properties, before the node is created.

udev is a generic kernel device manager. It runs as a daemon on a Linux system and listens (via netlink socket) to uevents the kernel sends out if a new device is initialized or a device is removed from the system.

 

devfs

devfs is a specific implementation of a device file system on Unix-like operating systems, used for presenting device files. The underlying mechanism of implementation may vary, depending on the OS.

Maintaining these special files on a general-purpose file system is inconvenient, and as it needs kernel assistance anyway, the idea of a special-purpose file system that is not stored on disk arose.

Also defining when devices are ready to appear is not entirely trivial. The 'devfs' approach is for the device driver to request creation and deletion of 'devfs' entries related to the devices it enables and disables.

 

Comparation

Linux 2.3.46pre5–2.6.17	devfs	/dev	Richard Gooch (Computer Scientist)	Implemented fully in the kernel. DEPRECATED: Users are encouraged to migrate to udev.
Linux 2.5–	udev on any fs, but usually tmpfs	/dev	Greg Kroah-Hartman, Kay Sievers and Dan Stekloff	Implemented largely in user space, device information is gathered from sysfs. Device files can be stored on a conventional general-purpose file system, or in a memory file system (tmpfs).
Linux 2.6.32–	devtmpfs with or without udev	/dev	Kay Sievers, Jan Blunck, Greg Kroah-Hartman	A hybrid kernel/userspace approach of a device filesystem to provide nodes before udev runs for the first time[8]

References

http://lwn.net/Articles/330985/

 (driver-core: devtmpfs -- driver core matained /dev tmpfs)

man udev

http://www.freedesktop.org/software/systemd/libudev/

(libudev reference manual)

http://en.wikipedia.org/wiki/Udev

(wiki: udev)

http://en.wikipedia.org/wiki/Devfs#devfs

(wiki: devfs)

Unsolved Problems

1. With devtmpfs support, is the initial rootfs necessary? As stated above, the /dev is available before the first device is registered with the core, so we don't have the chicken-or-egg problem anymore. (See http://my.oschina.net/u/158589/blog/75903 for more detail). In this situation, the root file system could be accessed because the device could now be registered with the core.