mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2026-05-20 05:10:27 -04:00
24a08b94de
git-svn-id: http://svn.linuxfromscratch.org/LFS/branches/testing/BOOK@4040 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
236 lines
11 KiB
XML
236 lines
11 KiB
XML
<?xml version="1.0" encoding="ISO-8859-1"?>
|
|
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
|
|
<!ENTITY % general-entities SYSTEM "../general.ent">
|
|
%general-entities;
|
|
]>
|
|
<sect1 id="ch-scripts-udev">
|
|
<title>Device and Module handling on an LFS system</title>
|
|
<?dbhtml filename="udev.html"?>
|
|
|
|
<indexterm zone="ch-scripts-udev">
|
|
<primary sortas="a-Udev">Udev</primary>
|
|
<secondary>usage</secondary></indexterm>
|
|
|
|
<para>In <xref linkend="chapter-building-system"/> we installed the udev
|
|
package. Before we go into the details regarding how this does its
|
|
job, a brief history of previous methods of handling devices is in
|
|
order.</para>
|
|
|
|
<para>Linux systems in general traditionally use a static device
|
|
creation method, whereby a great many device nodes are created under
|
|
<filename class="directory">/dev</filename> (sometimes literally
|
|
thousands of nodes), regardless of whether the corresponding hardware
|
|
devices actually exist. This is typically done via a
|
|
<command>MAKEDEV</command> script, which simply 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. As these device nodes will be
|
|
created each time the system boots, they will be stored on a
|
|
<systemitem class="filesystem">ramfs</systemitem> (a file system that
|
|
resides entirely in memory and does not take up any disk space).
|
|
Device nodes do not require much disk space, so the memory that is
|
|
used in negligable.</para>
|
|
|
|
<sect2>
|
|
<title>History</title>
|
|
|
|
<para>In Febraury of 2000, a new filesystem called <systemitem
|
|
class="filesystem">devfs</systemitem> was merged into the 2.3.46
|
|
kernel and was made generally 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 that 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 you are to allow device names to be configurable then
|
|
the device naming policy should be up to a system administrator, not
|
|
imposed upon them by any particular developer(s). <systemitem
|
|
class="filesystem">devfs</systemitem> 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.</para>
|
|
|
|
<para>With the development of the unstable 2.5 kernel tree, later
|
|
released as the 2.6 series of stable kernels, came a new virtual
|
|
filesystem called <systemitem class="filesystem">sysfs</systemitem>.
|
|
The job of <systemitem class="filesystem">sysfs</systemitem> is to
|
|
export a view of the system's structure to userspace processes. With
|
|
this userspace visible representation, the possibility of seeing a
|
|
userspace replacement for <systemitem
|
|
class="filesystem">devfs</systemitem> became much more
|
|
realistic.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Udev Implementation</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. Drivers that
|
|
have been compiled into the kernel directly register their objects
|
|
with <systemitem class="filesystem">sysfs</systemitem> as they are
|
|
detected by the kernel. For drivers compiled as modules, this will
|
|
happen when the module is loaded. Once the <systemitem
|
|
class="filesystem">sysfs</systemitem> filesystem is mounted (on
|
|
<filename class="directory">/sys</filename>), the data which the
|
|
built-in drivers registered with <systemitem
|
|
class="filesystem">sysfs</systemitem> is available to userspace
|
|
processes and to <command>udev</command> for device node creation.</para>
|
|
|
|
<para>The <command>S10udev</command> initscript takes care of creating
|
|
these device nodes when Linux is booted. This script starts with
|
|
registering <command>/sbin/udev</command> as a hotplug event handler.
|
|
Hotplug events (discussed below) should not be generated during this
|
|
stage, but <command>udev</command> is registered just in case they do
|
|
occur. The <command>udevstart</command> program then walks through
|
|
the <systemitem class="filesystem">/sys</systemitem> filesystem and
|
|
creates devices under <filename class="directory">/dev</filename> that
|
|
match the descriptions. For example,
|
|
<filename>/sys/class/tty/vcs/dev</filename> contains the string
|
|
<quote>7:0</quote>. <command>udevstart</command> uses this to create
|
|
<filename>/dev/vcs</filename> with major number <emphasis>7</emphasis>
|
|
and minor <emphasis>0</emphasis>. The permissions of each and every
|
|
device that <command>udevstart</command> creates are set using files
|
|
from the <filename
|
|
class="directory">/etc/udev.d/permissions.d/</filename> directory.
|
|
These are numbered in a similar fashion to the LFS bootscripts. If
|
|
<command>udev</command> cannot find a permissions file for the device
|
|
it is creating, it will default permissions to
|
|
<emphasis>600</emphasis> and ownership to
|
|
<emphasis>root:root</emphasis>. The names of the nodes created under
|
|
the <filename class="directory">/dev</filename> directory are
|
|
configured according to the rules specified in the files within the
|
|
<filename class="directory">/etc/udev/rules.d/</filename>
|
|
directory.</para>
|
|
|
|
<para>Once the above stage is complete, all devices that were already
|
|
present and have compiled-in drivers will be available for use. How
|
|
about those devices that have modular drivers?</para>
|
|
|
|
<para>We mentioned earlier the concept of a <quote>hotplug event
|
|
handler</quote>. When a new device connection is detected by the
|
|
kernel, the kernel will generate a hotplug event and look at the file
|
|
<filename>/proc/sys/kernel/hotplug</filename> to find out the
|
|
userspace program to handle that device's connection. The
|
|
<command>udev</command> initscript registered <command>udev</command>
|
|
as this handler. When these hotplug events are generated, the kernel
|
|
will tell <command>udev</command> to check the <filename
|
|
class="directory">/sys</filename> filesystem for the information
|
|
pertaining to this new device, and create the <filename
|
|
class="directory">/dev</filename> entry for it.</para>
|
|
|
|
<para>This brings us to one problem that exists with
|
|
<command>udev</command>, and likewise with <systemitem
|
|
class="filesystem">devfs</systemitem> before it. It is commonly
|
|
referred to as the <quote>chicken and egg</quote> problem. Most Linux
|
|
distrubtions handle loading modules via entries in
|
|
<filename>/etc/modules.conf</filename>. Access to a device node causes
|
|
the appropriate kernel module to load. With <command>udev</command>,
|
|
this method will not work because the device node does not exist until
|
|
the module is loaded. To solve this, the
|
|
<command>S05modules</command> bootscript was added to the
|
|
lfs-bootscripts package along with the
|
|
<filename>/etc/sysconfig/modules</filename> file. By adding module
|
|
names to the <filename>modules</filename> file, these modules will be
|
|
loaded when the computer is starting up. This allows
|
|
<command>udev</command> to detect the devices and create the
|
|
appropriate device nodes.</para>
|
|
|
|
<para>Note that on slower machines, or for drivers that create a lot
|
|
of device nodes, the process of creating devices may take a few
|
|
seconds to complete. This means that some device nodes may not be
|
|
immediately accessible.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Handling hotpluggable/dynamic devices</title>
|
|
|
|
<para>When you plug in a device, e.g. a USB MP3 player, the kernel
|
|
recognizes that the device is now connected and generates a hotplug
|
|
event. If the driver is already loaded (either because it was compiled
|
|
into the kernel, or it was loaded via the
|
|
<command>S05modules</command> bootscript) <command>udev</command> will
|
|
be called upon to create the relevant device node(s) according to the
|
|
<systemitem class="filesystem">sysfs</systemitem> data available in
|
|
<filename class="directory">/sys</filename>. If the driver for the
|
|
just plugged in device is available as a module but currently unloaded,
|
|
then attaching the device to the system will only cause the kernel's
|
|
bus driver to generate a hotplug event that notifies userspace of the
|
|
new device connection and it not being attached to a driver. In
|
|
effect, nothing happens and the device itself is not usable
|
|
yet.</para>
|
|
|
|
<para>If you are building a system that has a lot of drivers compiled
|
|
as modules rather than directly built into the kernel and using the
|
|
<command>S05modules</command> is not practical then the Hotplug
|
|
package (see <ulink url="http://linux-hotplug.sourceforge.net/"/>) can
|
|
be beneficial. When the Hotplug package is installed it will respond
|
|
to the aforementioned kernel's bus driver hotplug events. The Hotplug
|
|
package will load the appropriate module and make this device
|
|
available by creating the device node(s) for it.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Problems with creating devices</title>
|
|
|
|
<para>There are a few problems when it comes to automatically creating
|
|
devices nodes:</para>
|
|
|
|
<para>1) A kernel driver may not export its data to sysfs</para>
|
|
|
|
<para>This is most common with 3rd party drivers from outside the
|
|
kernel tree. These drivers will not end up having their device nodes
|
|
created. You can use the
|
|
<filename>/etc/sysconfig/createfiles</filename> configuration file to
|
|
manually create the devices. Consult the
|
|
<filename>devices.txt</filename> file inside your kernel documentation
|
|
or the documentation for that driver to find the proper major/minor
|
|
numbers.</para>
|
|
|
|
<para>2) A non-hardware device is required. This is most common with the
|
|
ALSA project's OSS compatibility module. These types of devices can
|
|
be handled in one of two ways:</para>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem><para>Adding the module names to
|
|
<filename>/etc/sysconfig/modules</filename></para></listitem>
|
|
<listitem><para>Use of an
|
|
<quote>install</quote> line in
|
|
<filename>/etc/modprobe.conf</filename>. Basically, this tells the
|
|
modprobe command <quote>when loading this module, also load this other
|
|
module, at the same time.</quote> For example:</para>
|
|
|
|
<screen><userinput>install snd-pcm modprobe -i snd-pcm ; modprobe snd-pcm-oss ; true</userinput></screen>
|
|
|
|
<para>This will cause the system to load both the
|
|
<emphasis>snd-pcm</emphasis> and <emphasis>snd-pcm-oss</emphasis>
|
|
modules when any request is made to load the driver
|
|
<emphasis>snd-pcm</emphasis>.</para></listitem>
|
|
</itemizedlist>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Useful reading</title>
|
|
|
|
<para>Some additional documentation that will be useful to
|
|
read:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>A Userspace Implementation of devfs -- <ulink
|
|
url="http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf"/></para></listitem>
|
|
<listitem><para>udev FAQ -- <ulink
|
|
url="http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ"/></para></listitem>
|
|
<listitem><para>The Linux Kernel Driver Model -- <ulink
|
|
url="http://public.planetmirror.com/pub/lca/2003/proceedings/papers/Patrick_Mochel/Patrick_Mochel.pdf"/></para></listitem>
|
|
</itemizedlist>
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|