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
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.
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.
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 udevd for device
node creation.
The S10udev 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.
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.
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 CLFS-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 is available in
/usr/share/doc/udev/writing_udev_rules/index.html
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 by Udev will cause udevd
to call out to /sbin/modprobe with the contents of the
MODALIAS
uevent environment variable (that 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.
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.
There are a few possible problems when it comes to automatically creating device nodes.
Udev will only load a module if it has a bus-specific alias and the
bus driver properly exports the necessary aliases to sysfs
. In other cases, one should
arrange module loading by other means. With Linux-2.6.39, Udev is
known to load properly-written drivers for INPUT, IDE, PCI, USB, SCSI,
SERIO and FireWire devices.
To determine if the device driver you require has the necessary
support for Udev, run modinfo with the module name as
the argument. Now try locating the device directory under
/sys/bus
and check whether there is
a modalias
file there.
If the modalias
file exists in sysfs
, the driver supports the device and
can talk to it directly, but doesn't have the alias, it is a bug in the
driver. Load the driver without the help from Udev and expect the issue
to be fixed later.
If there is no modalias
file in the relevant
directory under /sys/bus
, this
means that the kernel developers have not yet added modalias support to
this bus type. With Linux-2.6.39, this is the case with ISA
busses. Expect this issue to be fixed in later kernel versions.
Udev is not intended to load “wrapper” drivers such as snd-pcm-oss and non-hardware drivers such as loop at all.
If the “wrapper” module only enhances the functionality
provided by some other module (e.g., snd-pcm-oss
enhances the functionality of snd-pcm by making the
sound cards available to OSS applications), configure
modprobe to load the wrapper after Udev loads the
wrapped module. To do this, add an “install” line in
/etc/modprobe.conf
. For example:
install snd-pcm /sbin/modprobe -i snd-pcm ; \
/sbin/modprobe snd-pcm-oss ; true
If the module in question is not a wrapper and is useful by itself,
configure the S05modules bootscript to load this
module on system boot. To do this, add the module name to the
/etc/sysconfig/modules
file on a separate line.
This works for wrapper modules too, but is suboptimal in that case.
Either don't build the module, or blacklist it in
/etc/modprobe.conf
file as done with the
forte module in the example below:
blacklist forte
Blacklisted modules can still be loaded manually with the explicit modprobe command.
This usually happens if a rule unexpectedly matches a device. For example, a poorly-writen rule can match both a SCSI disk (as desired) and the corresponding SCSI generic device (incorrectly) by vendor. Find the offending rule and make it more specific, with the help of udevadm info.
This may be another manifestation of the previous problem. If not,
and your rule uses sysfs
attributes, it may be a kernel timing issue, to be fixed in later kernels.
For now, you can work around it by creating a rule that waits for the used
sysfs
attribute and appending
it to the /etc/udev/rules.d/10-wait_for_sysfs.rules
file. Please notify the CLFS Development list if you do so and it
helps.
Further text assumes that the driver is built statically into the kernel or already loaded as a module, and that you have already checked that Udev doesn't create a misnamed device.
Udev has no information needed to create a device node if a kernel
driver does not export its data to sysfs
.
This is most common with third party drivers from outside the kernel
tree. Create a static device node in
/lib/udev/devices
with the appropriate major/minor
numbers (see the file devices.txt
inside the kernel
documentation or the documentation provided by the third party driver
vendor). The static device node will be copied to
/dev
by the
S10udev bootscript.
This is due to the fact that Udev, by design, handles uevents and loads modules in parallel, and thus in an unpredictable order. This will never be “fixed”. You should not rely upon the kernel device names being stable. Instead, create your own rules that make symlinks with stable names based on some stable attributes of the device, such as a serial number or the output of various *_id utilities installed by Udev. See Section 11.7, “Creating custom symlinks to devices” and Networking Configuration for examples.
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
The sysfs
Filesystem
http://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/mochel.pdf