Context Navigation

-              r2f9131f
+              r81fd230
 <secondary>usage</secondary></indexterm>
+<para>See testing</para>
+<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>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, 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 devfs
+<ulink url="http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf"><phrase
+condition="pdf">http://www.kroah.com/linux/talks/ols_2003_udev_paper/
+Reprint-Kroah-Hartman-OLS2003.pdf</phrase></ulink></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"><phrase
+condition="pdf">http://public.planetmirror.com/pub/lca/2003/proceedings/papers/
+Patrick_Mochel/Patrick_Mochel.pdf</phrase></ulink></para></listitem>
+</itemizedlist>
+</sect2>
 </sect1>

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 81fd230 for chapter07/udev.xml

Legend:

chapter07/udev.xml

Download in other formats: