mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-01-31 11:21:59 +00:00
6ef50538b2
Regularized capital letters in <title> lines. Changed a dependent clause and made it independent. Smoothed out some bumpy verbiage in the "History" section. Removed superfluous verbiage. Clarified some trounbleshooting advice.
343 lines
16 KiB
XML
343 lines
16 KiB
XML
<?xml version="1.0" encoding="ISO-8859-1"?>
|
|
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
|
<!ENTITY % general-entities SYSTEM "../general.ent">
|
|
%general-entities;
|
|
]>
|
|
|
|
<sect1 id="ch-config-udev">
|
|
<?dbhtml filename="udev.html"?>
|
|
|
|
<title>Overview of Device and Module Handling</title>
|
|
|
|
<indexterm zone="ch-config-udev">
|
|
<primary sortas="a-Udev">Udev</primary>
|
|
<secondary>usage</secondary>
|
|
</indexterm>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<sect2>
|
|
<title>History</title>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>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>.</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Udev Implementation</title>
|
|
|
|
<sect3>
|
|
<title>Sysfs</title>
|
|
|
|
<para>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 /sys),
|
|
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).</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3 id='ch-config-udev-device-node-creation'>
|
|
<title>Device Node Creation</title>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>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.</para> </sect3>
|
|
|
|
<sect3 id="module-loading">
|
|
<title>Module Loading</title>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>The kernel itself is also able to load modules for network
|
|
protocols, filesystems, and NLS support on demand.</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Handling Hotpluggable/Dynamic Devices</title>
|
|
|
|
<para>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.</para>
|
|
|
|
</sect3>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Problems with Loading Modules and Creating Devices</title>
|
|
|
|
<para>There are a few possible problems when it comes to automatically
|
|
creating device nodes.</para>
|
|
|
|
<sect3>
|
|
<title>A Kernel Module Is Not Loaded Automatically</title>
|
|
|
|
<para>Udev will only load a module if it has a bus-specific alias and the
|
|
bus driver properly exports the necessary aliases to <systemitem
|
|
class="filesystem">sysfs</systemitem>. In other cases, one should
|
|
arrange module loading by other means. With Linux-&linux-version;, udev is
|
|
known to load properly-written drivers for INPUT, IDE, PCI, USB, SCSI,
|
|
SERIO, and FireWire devices.</para>
|
|
|
|
<para>To determine if the device driver you require has the necessary
|
|
support for udev, run <command>modinfo</command> with the module name as
|
|
the argument. Now try locating the device directory under
|
|
<filename class="directory">/sys/bus</filename> and check whether there is
|
|
a <filename>modalias</filename> file there.</para>
|
|
|
|
<para>If the <filename>modalias</filename> file exists in <systemitem
|
|
class="filesystem">sysfs</systemitem>, 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.</para>
|
|
|
|
<para>If there is no <filename>modalias</filename> file in the relevant
|
|
directory under <filename class="directory">/sys/bus</filename>, this
|
|
means that the kernel developers have not yet added modalias support to
|
|
this bus type. With Linux-&linux-version;, this is the case with ISA
|
|
busses. Expect this issue to be fixed in later kernel versions.</para>
|
|
|
|
<para>Udev is not intended to load <quote>wrapper</quote> drivers such as
|
|
<emphasis>snd-pcm-oss</emphasis> and non-hardware drivers such as
|
|
<emphasis>loop</emphasis> at all.</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>A Kernel Module Is Not Loaded Automatically, and Udev Is Not
|
|
Intended to Load It</title>
|
|
|
|
<para>If the <quote>wrapper</quote> module only enhances the
|
|
functionality provided by some other module (e.g.,
|
|
<emphasis>snd-pcm-oss</emphasis> enhances the functionality of
|
|
<emphasis>snd-pcm</emphasis> by making the sound cards available to OSS
|
|
applications), configure <command>modprobe</command> to load the wrapper
|
|
after udev loads the wrapped module. To do this, add a
|
|
<quote>softdep</quote> line to the corresponding
|
|
<filename>/etc/modprobe.d/<replaceable><filename></replaceable>.conf</filename>
|
|
file. For example:</para>
|
|
|
|
<screen role="nodump"><literal>softdep snd-pcm post: snd-pcm-oss</literal></screen>
|
|
|
|
<para>Note that the <quote>softdep</quote> command also allows
|
|
<literal>pre:</literal> dependencies, or a mixture of both
|
|
<literal>pre:</literal> and <literal>post:</literal> dependencies. See
|
|
the <filename>modprobe.d(5)</filename> manual page for more information
|
|
on <quote>softdep</quote> syntax and capabilities.</para>
|
|
|
|
<para revision="sysv">If the module in question is not a wrapper and is
|
|
useful by itself, configure the <command>modules</command> bootscript to
|
|
load this module on system boot. To do this, add the module name to the
|
|
<filename>/etc/sysconfig/modules</filename> file on a separate line.
|
|
This works for wrapper modules too, but is suboptimal in that case.</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Udev Loads Some Unwanted Module</title>
|
|
|
|
<para>Either don't build the module, or blacklist it in a
|
|
<filename>/etc/modprobe.d/blacklist.conf</filename> file as done with the
|
|
<emphasis>forte</emphasis> module in the example below:</para>
|
|
|
|
<screen role="nodump"><literal>blacklist forte</literal></screen>
|
|
|
|
<para>Blacklisted modules can still be loaded manually with the
|
|
explicit <command>modprobe</command> command.</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Udev Creates a Device Incorrectly, or Makes the Wrong Symlink</title>
|
|
|
|
<para>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 the
|
|
<command>udevadm info</command> command.</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Udev Rule Works Unreliably</title>
|
|
|
|
<para>This may be another manifestation of the previous problem. If not,
|
|
and your rule uses <systemitem class="filesystem">sysfs</systemitem>
|
|
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
|
|
<systemitem class="filesystem">sysfs</systemitem> attribute and appending
|
|
it to the <filename>/etc/udev/rules.d/10-wait_for_sysfs.rules</filename>
|
|
file (create this file if it does not exist). Please notify the LFS
|
|
Development list if you do so and it helps.</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Udev Does Not Create a Device</title>
|
|
|
|
<para>First, be certain that the driver is built into the
|
|
kernel or already loaded as a module, and that
|
|
udev isn't creating a misnamed device.</para>
|
|
|
|
<para>If a kernel driver does not export its data to
|
|
<systemitem class="filesystem">sysfs</systemitem>, udev lacks the
|
|
information needed to create a device node. This is most likely to happen
|
|
with third party drivers from outside the kernel tree. Create a static
|
|
device node in <filename>/usr/lib/udev/devices</filename> with the
|
|
appropriate major/minor numbers (see the file
|
|
<filename>devices.txt</filename> inside the kernel documentation or the
|
|
documentation provided by the third party driver vendor). The static
|
|
device node will be copied to <filename class="directory">/dev</filename>
|
|
by <command>udev</command>.</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Device Naming Order Changes Randomly After Rebooting</title>
|
|
|
|
<para>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 <quote>fixed</quote>. 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 <xref linkend="ch-config-symlinks"/> and
|
|
<xref linkend="ch-config-network"/> for examples.</para>
|
|
|
|
</sect3>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Useful Reading</title>
|
|
|
|
<para>Additional helpful documentation is available at the following
|
|
sites:</para>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>A Userspace Implementation of <systemitem class="filesystem">devfs</systemitem>
|
|
<ulink url="http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf"/></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The <systemitem class="filesystem">sysfs</systemitem> Filesystem
|
|
<ulink url="https://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/mochel.pdf"/></para>
|
|
</listitem>
|
|
|
|
<!-- No longer available
|
|
<listitem>
|
|
<para>Pointers to further reading
|
|
<ulink url="http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html"/>
|
|
</para>
|
|
</listitem>
|
|
-->
|
|
</itemizedlist>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|