Zen

Source string Source string

765/10000 · 765

The string is read only.

English Actions
Overview of Device and Module Handling
Udev
usage
In <xref linkend="chapter-building-system"/>, we installed the udev daemon when <phrase revision="sysv">eudev</phrase> <phrase revision="systemd">systemd</phrase> was built. Before we go into the details regarding how udev works, a brief history of previous methods of handling devices is in order.
Linux systems in general traditionally used a static device creation method, whereby a great many device nodes were created under <filename class="directory">/dev</filename> (sometimes literally thousands of nodes), regardless of whether the corresponding hardware devices actually existed. This was typically done via a <command>MAKEDEV</command> script, which contained a number of calls to the <command>mknod</command> program with the relevant major and minor device numbers for every possible device that might exist in the world.
Using the udev method, device nodes are only created for those devices which are detected by the kernel. These device nodes are created each time the system boots; they are stored in a <systemitem class="filesystem">devtmpfs</systemitem> file system (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.
History
In February 2000, a new filesystem called <systemitem class="filesystem">devfs</systemitem> 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 <systemitem class="filesystem">devfs</systemitem> 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 configurable, the device naming policy should be chosen by system administrators, and not imposed on them by the developer(s). The <systemitem class="filesystem">devfs</systemitem> file system also suffered from race conditions that were inherent in its design; these could not be fixed without a substantial revision of the kernel. <systemitem class="filesystem">devfs</systemitem> was marked as deprecated for a long time, and was finally removed from the kernel in June, 2006.
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 <systemitem class="filesystem">sysfs</systemitem> came to be. The job of <systemitem class="filesystem">sysfs</systemitem> is to provide information about the system's hardware configuration to userspace processes. With this userspace-visible representation, it became possible to develop a userspace replacement for <systemitem class="filesystem">devfs</systemitem>.
Udev Implementation
Sysfs
The <systemitem class="filesystem">sysfs</systemitem> filesystem was mentioned briefly above. One may wonder how <systemitem class="filesystem">sysfs</systemitem> 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 register their objects in <systemitem class="filesystem">sysfs</systemitem> (devtmpfs internally) as they are detected by the kernel. For drivers compiled as modules, registration happens when the module is loaded. Once the <systemitem class="filesystem">sysfs</systemitem> filesystem is mounted (on <filename class="directory">/sys</filename>), data which the drivers have registered with <systemitem class="filesystem">sysfs</systemitem> are available to userspace processes and to udevd for processing (including modifications to device nodes).
Device Node Creation
Device files are created by the kernel in the <systemitem class="filesystem">devtmpfs</systemitem> file system. Any driver that wishes to register a device node will use the <systemitem class="filesystem">devtmpfs</systemitem> (via the driver core) to do it. When a <systemitem class="filesystem">devtmpfs</systemitem> instance is mounted on <filename class="directory">/dev</filename>, the device node will initially be exposed to userspace with a fixed name, permissions, and owner.
A short time later, the kernel will send a uevent to <command> udevd</command>. Based on the rules specified in the files within the <filename class="directory">/etc/udev/rules.d</filename>, <filename class="directory">/usr/lib/udev/rules.d</filename>, and <filename class="directory">/run/udev/rules.d</filename> directories, <command> udevd</command> will create additional symlinks to the device node, or change its permissions, owner, or group, or modify the internal <command>udevd</command> database entry (name) for that object.
The rules in these three directories are numbered and all three directories are merged together. If <command>udevd</command> can't find a rule for the device it is creating, it will leave the permissions and ownership at whatever <systemitem class="filesystem">devtmpfs</systemitem> used initially.
Module Loading
Device drivers compiled as modules may have aliases built into them. Aliases are visible in the output of the <command>modinfo</command> program and are usually related to the bus-specific identifiers of devices supported by a module. For example, the <emphasis>snd-fm801</emphasis> driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801, and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>. For most devices, the bus driver exports the alias of the driver that would handle the device via <systemitem class="filesystem">sysfs</systemitem>. E.g., the <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file might contain the string <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>. The default rules provided with udev will cause <command>udevd</command> to call out to <command>/sbin/modprobe</command> with the contents of the <envar>MODALIAS</envar> uevent environment variable (which should be the same as the contents of the <filename>modalias</filename> file in sysfs), thus loading all modules whose aliases match this string after wildcard expansion.
In this example, this means that, in addition to <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted) <emphasis>forte</emphasis> driver will be loaded if it is available. See below for ways in which the loading of unwanted drivers can be prevented.
The kernel itself is also able to load modules for network protocols, filesystems, and NLS support on demand.
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 uevent. This uevent is then handled by <command>udevd</command> as described above.
Problems with Loading Modules and Creating Devices

Loading…

User avatar None

Source string added

  1. Linux From Scratch 11.3
  2. chapter09_udev
  3. English
The main problem with the approach adopted by <systemitem class="filesystem">devfs</systemitem> 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 configurable, the device naming policy should be chosen by system administrators, and not imposed on them by the developer(s). The <systemitem class="filesystem">devfs</systemitem> file system also suffered from race conditions that were inherent in its design; these could not be fixed without a substantial revision of the kernel. <systemitem class="filesystem">devfs</systemitem> was marked as deprecated for a long time, and was finally removed from the kernel in June, 2006.
a year ago
Browse all string changes

Things to check

Unpluralised

The string is used as plural, but not using plural forms

Reset

Glossary

English English
No related strings found in the glossary.

String information

Source string description
type: Content of: <sect1><sect2><para>
Flags
read-only
Source string location
lfs-en/chapter09/udev.xml:50
String age
a year ago
Last updated
9 months ago
Source string age
a year ago
Translation file
string 9