Every device driver carries a list of known aliases for devices it can handle. The list is
contained in the kernel module le itself. The program depmod reads the ID lists and
creates the le modules.alias in the kernel's /lib/modules directory for all
currently available modules. With this infrastructure, module loading is as easy as
calling modprobe for every event that carries a MODALIAS key. If modprobe
$MODALIAS is called, it matches the device alias composed for the device with the
aliases provided by the modules. If a matching entry is found, that module is loaded.
All this is automatically triggered by udev.
12.4 Booting and Initial Device Setup
All device events happening during the boot process before the udev daemon is running
are lost, because the infrastructure to handle these events resides on the root le system
and is not available at that time. To cover that loss, the kernel provides a uevent le
located in the device directory of every device in the sysfs le system. By writing
add to that le, the kernel resends the same event as the one lost during boot. A simple
loop over all uevent les in /sys triggers all events again to create the device nodes
and perform device setup.
As an example, a USB mouse present during boot may not be initialized by the early
boot logic, because the driver is not available at that time. The event for the device
discovery was lost and failed to nd a kernel module for the device. Instead of manually
searching for possibly connected devices, udev just requests all device events from
the kernel after the root le system is available, so the event for the USB mouse device
just runs again. Now it nds the kernel module on the mounted root le system and the
USB mouse can be initialized.
From userspace, there is no visible difference between a device coldplug sequence and
a device discovery during runtime. In both cases, the same rules are used to match and
the same congured programs are run.
Dynamic Kernel Device Management with udev 209
