In Installing Basic System Software, we installed the Eudev 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.
In February 2000, a new filesystem called devfs, which dynamically created device nodes
as devices were found by the kernel, 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 suffered from race conditions that were inherent in
its design and could not be fixed without a substantial revision
to the kernel. It was marked deprecated with the release of the
2.6 kernel series, and was removed entirely as of version 2.6.18.
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. 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. With this userspace-visible
representation, the possibility of seeing a userspace replacement
for devfs became much more
realistic.
Shortly after the introduction of sysfs, work began on a program called Udev to
advantage of it. The udev daemon made calls to
mknod() to create device nodes in
/dev dynamically, based on the
information from sysfs, in
/sys. For example, /sys/class/tty/vcs/dev contains the string
“7:0”. This string was
used by udev to
create a device node with major number 7 and minor number 0.
Linux kernel version 2.6.32 introduced a new virtual file system
called devtmpfs, an improved
replacement for devfs. This
allows device nodes to once again be dynamically created by the
kernel, without many of the problems of devfs. As of version 176, Udev no longer
creates device nodes itself, instead relying on devtmpfs to do so.
In 2010, development began on systemd, an alternate init implementation. Starting with Udev 183, Udev's source tree was merged with systemd. Several Gentoo developers who disagreed with this merge announced a project fork called Eudev in December 2012, created by extracting the Udev code from systemd. One of the goals of Eudev is to allow for easier installation and usage of udevd without the need for the rest of systemd.
By default, device nodes created by the kernel in a devtmpfs are owned by root:root and have 600 permissions. udevd can modify ownership and
permissions of the nodes under the /dev directory, and can also create additional
symlinks, based on rules specified in the files within the
/etc/udev/rules.d, /lib/udev/rules.d, and /run/udev/rules.d directories. The names for
these files start with a number, to indicate the order in which
they are run, and they have a .rules
extension (udevd will
ignore files with any other extension). All of the rules files from
these directories are combined into a single list, sorted by
filename, and run in that order. In the event of a conflict, where
a rules file with the same name exists in two or more of these
directories, the rules in /etc take
the highest priority, followed by rules files in /run, and finally /lib. Any device for which a rule cannot be found
will just be ignored by udevd and be left at the defaults
defined by the kernel, as described above.
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 Eudev 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.
There are a few possible problems when it comes to automatically creating device nodes.
Eudev 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-3.14.13, Eudev
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 Eudev, 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
Eudev 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-3.14.13, this is the case
with ISA busses. Expect this issue to be fixed in later kernel
versions.
Eudev 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 Eudev loads the wrapped module. To do this, add an
“install” line to a file
in /etc/modprobe.d. 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.d 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-written 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.
This is due to the fact that Eudev, 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 Eudev. 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