path: root/chapter07/udev.xml

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/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 works,
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 contains 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. 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
<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 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 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 <systemitem
class="filesystem">devfs</systemitem> 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.</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
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> are 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> This string is used by <command>udevstart</command>
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. What 
about those devices that have modular drivers?</para>

<para>Earlier, we mentioned 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 that handles the device's connection.  The
<command>udev</command> initscript registered <command>udevsend</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, such a Universal Serial Bus (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 because 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 building a system that has a lot of drivers compiled as
modules rather than directly built into the kernel, using the
<command>S05modules</command> may not be practical. The Hotplug
package (see <ulink url="http://linux-hotplug.sourceforge.net/"/>) can
be beneficial in these cases. 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 known problems when it comes to automatically creating
devices nodes:</para>

<para>1) A kernel driver may not export its data to <systemitem
class="filesystem">sysfs</systemitem>.</para>
   
<para>This is most common with third party drivers from outside the
kernel tree.  These drivers will not end up having their device nodes
created.  Use the
<filename>/etc/sysconfig/createfiles</filename> configuration file to
manually create the devices. Consult the
<filename>devices.txt</filename> file inside the 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 Advanced Linux Sound Architecture (ALSA) project's Open Sound
System (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>Using an
<quote>install</quote> line in
<filename>/etc/modprobe.conf</filename>. This tells the
<command>modprobe</command> 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>Additional helpful documentation is available at the following
sites:</para>

<itemizedlist>
<listitem><para remap="verbatim">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 remap="verbatim">udev FAQ
<ulink url="http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ"/></para></listitem>

<listitem><para remap="verbatim">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>