Linux From Scratch - Version 7.0
201
7.4.2.2. Udev Bootscripts
The /etc/rc.d/init.d/udev initscript takes care of creating device nodes when Linux is booted. The script unsets the
uevent handler from the default of /sbin/hotplug. This is done because the kernel no longer needs to call out to an
external binary. Instead udevd will listen on a netlink socket for uevents that the kernel raises. Next, the bootscript
copies any static device nodes that exist in /lib/udev/devices to /dev. This is necessary because some
devices, directories, and symlinks are needed before the dynamic device handling processes are available during
the early stages of booting a system, or are required by udevd itself. Creating static device nodes in /lib/udev/
devices also provides an easy workaround for devices that are not supported by the dynamic device handling
infrastructure. The bootscript then starts the Udev daemon, udevd, which will act on any uevents it receives. Finally,
the bootscript forces the kernel to replay uevents for any devices that have already been registered and then waits
for udevd to handle them.
The /etc/rc.d/init.d/udev_retry initscript takes care of re-triggering events for subsystems whose rules may rely
on filesystems that are not mounted until the mountfs script is run (in particular, /usr and /var may cause this).
This script runs after the mountfs script, so those rules (if re-triggered) should succeed the second time around.
It is configured from the /etc/sysconfig/udev_retry file; any words in this file other than comments are
considered subsystem names to trigger at retry time. (To find the subsystem of a device, use udevadm info --
attribute-walk.)
7.4.2.3. Device Node Creation
To obtain the right major and minor number for a device, Udev relies on the information provided by sysfs in /
sys. For example, /sys/class/tty/vcs/dev contains the string “7:0”. This string is used by udevd to create
a device node with major number 7 and minor 0. The names and permissions of the nodes created under the /
dev directory are determined by rules specified in the files within the /etc/udev/rules.d/ directory. These
are numbered in a similar fashion to the LFS-Bootscripts package. If udevd can't find a rule for the device it is
creating, it will default permissions to 660 and ownership to root:root. Documentation on the syntax of the Udev rules
configuration files are available in /usr/share/doc/udev-173/writing_udev_rules/index.html
7.4.2.4. Module Loading
Device drivers compiled as modules may have aliases built into them. Aliases are visible in the output of the
modinfo program and are usually related to the bus-specific identifiers of devices supported by a module. For
example, the snd-fm801 driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801, and has an alias
of “pci:v00001319d00000801sv*sd*bc04sc01i*”. For most devices, the bus driver exports the alias of the driver
that would handle the device via sysfs. E.g., the /sys/bus/pci/devices/0000:00:0d.0/modalias
file might contain the string “pci:v00001319d00000801sv00001319sd00001319bc04sc01i00”. The default rules
provided with Udev will cause udevd to call out to /sbin/modprobe with the contents of the MODALIAS uevent
environment variable (which should be the same as the contents of the modalias file in sysfs), thus loading all
modules whose aliases match this string after wildcard expansion.
In this example, this means that, in addition to snd-fm801, the obsolete (and unwanted) forte 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.
7.4.2.5. 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 udevd as described above.
Comentarios a estos manuales