devfs

July 28, 2000
J. Corbet

Richard Gooch's presentation got off to a bit of a slow start, as the video projector displayed the dreaded "has reached maximal mount count, check forced" message from his laptop. While we were waiting, he asked a couple of questions:

How many of you have heard of devfs? At least 90% of the (large) audience raised hands.
How many of you like it? Maybe 25%.

This poll shows the sort of uphill battle that Richard has been fighting for years. He has written code to solve a set of problems he sees in how devices are managed, but quite a few people disagree with his solution, often for reasons that are not entirely clear. Some members of audience were overtly disdainful and comtemptuous when asking their questions. It does not seem like the best way to treat somebody who is trying to make a contribution.

The problems that Richard sees with the current /dev implementation include:

"Musical devices." If you run a SCSI system, and add or remove a device, all of the other devices (of the same type, at least) can change names. Systems boot badly when their filesystems no longer mount.
Device numbers are an increasingly tight resource. The device number space can be increased in 2.5, but that brings problems of its own: 256 device numbers are easily handled with an in-kernel array; many thousands of device numbers may require a different approach. Expanding device numbers may also break libc5, which numerous people (notably, Richard Gooch) are still using.
Currently, Linux systems ship with thousands of static device nodes in /dev. These nodes are constantly multiplying, bear no relationship to the actual hardware installed on the system, require a central authority for device numbers, and require duplication of information between /dev, the drivers for the devices, devices.txt, and the MAKEDEV script.
Properly supporting hotplug devices requires a dynamic device directory.
A static /dev scales poorly to large systems.

Richard's solution, of course, is devfs, a dynamic device filesystem. Under devfs, drivers create and remove their own device nodes, so the contents of /dev reflect the hardware that is actually present on the system. Device numbers have been eliminated altogether - at least, for char devices (the block subsystem still requires major numbers to function). It can provide more than one view of the hardware on the system; one subdirectory of /dev can show all disks on the system, while another shows the contents of each system bus. Vendor-specific directories are also possible, freeing vendors from the need to clear names with any central authority.

Richard discussed a number of devfs enhancements on his list:

Various new namespaces for devices. Disk partitions, for example, could be found by the UUID of the filesystems they hold. Another namespace would list devices by their "world-wide ID." Finally, a /dev/bus namespace would reflect the physical structure of the system.
Integration with the hotplug subsystem. As system hardware becomes increasingly dynamic, Linux will need something that looks a lot like devfs.
Use of the dentry cache to hold much of the devfs database.
Getting away from device numbers entirely - this is a 2.5 issue.
Changing the way the SCSI subsystem uses devfs; with the right tweaks, SCSI could support far more devices in the 2.4 kernel.

The acceptance of devfs is growing, as can be seen by the large attendance at this talk. It will likely always be somewhat controversial, however, and there are still no major distributions which are using devfs. In the future, though, either devfs or something that looks much like it will likely be needed to address the challenges brought by modern hardware.

Back to OLS 2001 coverage