11.5. Device and Module Handling on a CLFS System

#### Cross-Compiled Linux From Scratch - Version 1.0.0rc1-x86_64-Multilib

### Chapter 11. Setting Up System Bootscripts

- Prev

  How Do These Bootscripts Work?

- Next

  Configuring the setclock Script

- Up.
- Home

# 11.5. Device and Module Handling on a CLFS System

In Installing Basic System Software, we installed the Udev package. Before we go into the details regarding how this works, a brief history of previous methods of handling devices is in order.

Linux systems in general traditionally use a static device creation method, whereby a great many device nodes are created under `/dev` (sometimes literally thousands of nodes), regardless of whether the corresponding hardware devices actually exist. This is typically done via a MAKEDEV script, which contains a number of calls to the mknod program with the relevant major and minor device numbers for every possible device that might exist in the world. Using the Udev method, only those devices which are detected by the kernel get device nodes created for them. Because these device nodes will be created each time the system boots, they will be stored on a `tmpfs` (a virtual file system that resides entirely in system memory). Device nodes do not require much space, so the memory that is used is negligible.

## 11.5.1. History

In February 2000, a new filesystem called `devfs` was merged into the 2.3.46 kernel and was made available during the 2.4 series of stable kernels. Although it was present in the kernel source itself, this method of creating devices dynamically never received overwhelming support from the core kernel developers.

The main problem with the approach adopted by `devfs` was the way it handled device detection, creation, and naming. The latter issue, that of device node naming, was perhaps the most critical. It is generally accepted that if device names are allowed to be configurable, then the device naming policy should be up to a system administrator, not imposed on them by any particular developer(s). The `devfs` file system also suffers from race conditions that are inherent in its design and cannot be fixed without a substantial revision to the kernel. It has also been marked as deprecated due to a lack of recent maintenance.

With the development of the unstable 2.5 kernel tree, later released as the 2.6 series of stable kernels, a new virtual filesystem called `sysfs` came to be. The job of `sysfs` is to export a view of the system's hardware configuration to userspace processes. With this userspace-visible representation, the possibility of seeing a userspace replacement for `devfs` became much more realistic.

## 11.5.2. Udev Implementation

The `sysfs` filesystem was mentioned briefly above. One may wonder how `sysfs` knows about the devices present on a system and what device numbers should be used for them. Drivers that have been compiled into the kernel directly register their objects with `sysfs` as they are detected by the kernel. For drivers compiled as modules, this registration will happen when the module is loaded. Once the `sysfs` filesystem is mounted (on `/sys`), data which the built-in drivers registered with `sysfs` are available to userspace processes and to udev for device node creation.

The S10udev initscript takes care of creating these device nodes when Linux is booted. This script starts by registering /sbin/udevsend as a hotplug event handler. Hotplug events (discussed below) are not usually generated during this stage, but udev is registered just in case they do occur. The udevstart program then walks through the `/sys` filesystem and creates devices under `/dev` that match the descriptions. For example, `/sys/class/tty/vcs/dev` contains the string “7:0” This string is used by udevstart to create `/dev/vcs` with major number 7 and minor 0. The names and permissions of the nodes created under the `/dev` directory are configured according to the rules specified in the files within the `/etc/udev/rules.d/` directory. These are numbered in a similar fashion to the CLFS-Bootscripts package. If udev can't find a rule for the device it is creating, it will default permissions to 660 and ownership to root:root.

Once the above stage is complete, all devices that were already present and have compiled-in drivers will be available for use. This leads us to the devices that have modular drivers.

Earlier, we mentioned the concept of a “hotplug event handler.” When a new device connection is detected by the kernel, the kernel will generate a hotplug event and look at the file `/proc/sys/kernel/hotplug` to determine the userspace program that handles the device's connection. The udev bootscript registered udevsend as this handler. When these hotplug events are generated, the kernel will tell udev to check the `/sys` filesystem for the information pertaining to this new device and create the `/dev` entry for it.

This brings us to one problem that exists with udev, and likewise with `devfs` before it. It is commonly referred to as the “chicken and egg” problem. Most Linux distributions handle loading modules via entries in `/etc/modules.conf`. Access to a device node causes the appropriate kernel module to load. With udev, this method will not work because the device node does not exist until the module is loaded. To solve this, the S05modules bootscript was added to the CLFS-Bootscripts package, along with the `/etc/sysconfig/modules` file. By adding module names to the `modules` file, these modules will be loaded when the computer starts up. This allows udev to detect the devices and create the appropriate device nodes.

Note that on slower machines or for drivers that create a lot of device nodes, the process of creating devices may take a few seconds to complete. This means that some device nodes may not be immediately accessible.

## 11.5.3. Handling Hotpluggable/Dynamic Devices

When you plug in a device, such as a Universal Serial Bus (USB) MP3 player, the kernel recognizes that the device is now connected and generates a hotplug event. If the driver is already loaded (either because it was compiled into the kernel or because it was loaded via the S05modules bootscript), udev will be called upon to create the relevant device node(s) according to the `sysfs` data available in `/sys`.

If the driver for the just plugged in device is available as a module but currently unloaded, the Hotplug package will load the appropriate module and make this device available by creating the device node(s) for it.

## 11.5.4. Problems with Creating Devices

There are a few known problems when it comes to automatically creating device nodes:

1) A kernel driver may not export its data to `sysfs`.

This is most common with third party drivers from outside the kernel tree. Udev will be unable to automatically create device nodes for such drivers. Use the `/etc/sysconfig/createfiles` configuration file to manually create the devices. Consult the `devices.txt` file inside the kernel documentation or the documentation for that driver to find the proper major/minor numbers.

2) A non-hardware device is required. This is most common with the Advanced Linux Sound Architecture (ALSA) project's Open Sound System (OSS) compatibility module. These types of devices can be handled in one of two ways:

- Adding the module names to `/etc/sysconfig/modules`

- Using an “install” line in `/etc/modprobe.conf`. This tells the modprobe command “when loading this module, also load this other module, at the same time.” For example:

      install snd-pcm modprobe -i snd-pcm ; modprobe \
          snd-pcm-oss ; true

  This will cause the system to load both the snd-pcm and snd-pcm-oss modules when any request is made to load the driver snd-pcm.

## 11.5.5. Useful Reading

Additional helpful documentation is available at the following sites:

- A Userspace Implementation of `devfs` http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf

- udev FAQ http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

- The Linux Kernel Driver Model http://public.planetmirror.com/pub/lca/2003/proceedings/papers/Patrick_Mochel/Patrick_Mochel.pdf

- Prev

  How Do These Bootscripts Work?

- Next

  Configuring the setclock Script

- Up.
- Home.