source: chapter07/udev.xml@ 5ba3d1d

<?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 &amp; 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 (or similar), 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 has never received
overwhelming support from the core kernel developers.  The main
problems with the approach adopted by
<systemitem class="filesystem">devfs</systemitem> were seen to be that it
handled device detection, creation and naming all in the one place.
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 are cannot be fixed without a considerable
rewrite of the entire code. 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 for <command>udev</command> to create device nodes from.</para>

<para>The <command>S10udev</command> initscript takes care of creating
these device nodes when Linux is booted. The first thing this script
does is registering <command>/sbin/udev</command> as a hotplug event
handler.  Hotplug events should not be generated during this stage,
but it is registered just in case they do.  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 our bootscripts.  If
<command>udev</command> can't find a permissions file for the device
it is creating, it will default to <emphasis>600</emphasis> and
<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 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, a bootscript was added,
<command>S05modules</command> 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 them and create device nodes
for.</para>

<para>One thing to note is 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
recognises that the device is now connected and generates a hotplug
event. The driver will already have been loaded (either because it was
compiled into the kernel, or it was loaded via the
<command>S05modules</command> bootscript) so <command>udev</command>
will simply be called upon to create the relevant device node
according to the <systemitem class="filesystem">sysfs</systemitem>
data available in <filename class="directory">/sys</filename>.</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.  You may end up consulting 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 2 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>