Dynamic Creation of Device Files
Traditionally the device nodes in /dev were created statically on a disk-based filesystem. With more and more supported devices, more and more entries had to be installed and managed — around 20,000 entries for typical distributions. Most of these entries are not necessary on an average system, which contains only a handful of devices — especially compared to the 20,000 available device nodes. Nearly all distributions have thus switched to managing the contents of /dev with udevd, a daemon that allows dynamic device file creation from userland.
Figure 6-3: Managing device nodes from userspace with udevd.
The basic idea of udevd is depicted in Figure 6-3. Even if the device files are managed from userland, support from the kernel is an absolute necessity: It is impossible to determine which devices are available in the system otherwise.
Whenever the kernel detects a device, a kernel object (kobject; see Chapter 1) is created. The object is exported to userland with the help of the sysfs filesystem (see Section 10.3 for more details). Additionally, the kernel sends a hotplug message to userspace, as is discussed in Section 7.4.
When a new device is found during startup or attached at run time (like USB sticks), the hotplug messages generated by the kernel include which major and minor numbers the driver assigns for the device. All the udevd daemon needs to do is listen to these messages. When a new device is registered, the entries in /dev are created, and the device can be accessed from userland.
Since the introduction of the udev mechanism, /dev is not contained on a disk-based filesystem anymore, but uses tmpfs — a slight variation on the RAM-disk filesystem ramfs. This implies that device nodes are not persistent across system boots. When a device is removed during the downtime, the corresponding device node will not be contained in /dev anymore. Since it will also not be created anew — there is no message from the kernel that the device was registered since it is not present in the system anymore — this ensures that no old and obsolete devices files are aggregated in /dev. Although nothing would prevent udevd from working on a disk-based filesystem, this would not really make sense.
In addition to the task outlined above, the udev daemon also assumes some more responsibilities like ensuring that device nodes for specific devices always have the same name irrespective of the device topology. For instance, users usually desire to have the same device node for USB sticks independent of when and where they are plugged in. Refer to the manual page udevd(5) for more information on how the udev daemon handles such cases — this is a pure userspace problem and nothing the kernel needs to be concerned about.
Continue reading here: Device Addressing Using loctls
Was this article helpful?