Linux Kernel Architecture

Chapter 6: Device Drivers

fileDocumentation/devices.txtwith current data at the time of kernel release. Pre-processor constants,

which are easier to read than the raw number, are defined in<major.h>. The numbers here are synchro-

nized with the assignments in the LANANA list, but not all LANANA-assigned numbers also have a

pre-processor symbol. SCSI disks (as required by SATA devices) and TTY devices with major numbers 8

and 4, respectively, are represented by the following pre-processor symbols:

<major.h>

...

#define TTY_MAJOR 4

...

#define SCSI_DISK0_MAJOR 8

...

Dynamic Creation of Device Files

Traditionally the device nodes in/devwere 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/devwithudevd, a daemon that allows

dynamic device file creation from userland.

Kernel udevd

create

new /dev/sda

device /dev/sdb

node

Hotplug message:

New device

Figure 6-3: Managing device nodes from

userspace withudevd.

The basic idea ofudevdis 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 mes-

sages generated by the kernel include which major and minor numbers the driver assigns for the device.

All theudevddaemon needs to do is listen to these messages. When a new device is registered, the entries

in/devare created, and the device can be accessed from userland.

Since the introduction of the udev mechanism,/devis 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/devanymore. 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

preventudevdfrom working on a disk-based filesystem, this would not really make sense.