source: chapter07/udev.xml@ fb6fcc5

<?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">
  <?dbhtml filename="udev.html"?>

  <title>Device and Module Handling on an LFS System</title>

  <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.</para>

  <para>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">tmpfs</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 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 hardware configuration 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>

    <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 directly register their objects with
      <systemitem class="filesystem">sysfs</systemitem> as they are detected by
      the kernel. For drivers compiled as modules, this registration will happen
      when the module is loaded. Once the <systemitem
      class="filesystem">sysfs</systemitem> filesystem is mounted (on <filename
      class="directory">/sys</filename>), 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>
    </sect3>

    <sect3>
      <title>Udev Bootscript</title>

      <para>The <command>S10udev</command> initscript takes care of creating
      device nodes when Linux is booted. The script starts by unsetting the
      hotplug event handler from the default of <command>/sbin/hotplug</command>
      This is done because, instead of the kernel calling out to an external
      binary, <command>udev</command> will listen on a netlink socket for
      hotplug events that the kernel raises. The bootscript copies any static
      device nodes that exist in <filename
      class="directory">/lib/udev/devices</filename> to <filename
      class="directory">/dev</filename>. This is necessary because some devices
      are needed before the dynamic device handling processes are available
      during the early stages of booting a system.  Creating static device nodes
      in <filename class="directory">/lib/udev/devices</filename> also provides
      an easy workaround for devices that are not supported by the dynamic
      device handling infrastructure.  The bootscript then starts the Udev
      daemon, <command>udevd</command>, which will act on any hotplug events it
      receives. Finally, the bootscript &quot;coldplugs&quot; any devices that
      have already been registered with the kernel by forcing them to raise
      hotplug events which <command>udevd</command> will then handle.</para>
    </sect3>

    <sect3>
      <title>Device Node Creation</title>

      <para>To obtain the right major and minor number for a device, Udev relies
      on the information provided by <systemitem
      class="filesystem">sysfs</systemitem> in <filename
      class="directory">/sys</filename>.  For example,
      <filename>/sys/class/tty/vcs/dev</filename> contains the string
      <quote>7:0</quote>. This string is used by <command>udevd</command>
      to create a device node with major number <emphasis>7</emphasis> and minor
      <emphasis>0</emphasis>. The names and permissions of the nodes created
      under the <filename class="directory">/dev</filename> directory are
      determined by rules specified in the files within the <filename
      class="directory">/etc/udev/rules.d/</filename> directory. These are
      numbered in a similar fashion to the LFS-Bootscripts package. If
      <command>udevd</command> can't find a rule for the device it is creating,
      it will default permissions to <emphasis>660</emphasis> and ownership to
      <emphasis>root:root</emphasis>. Documentation on the syntax of the Udev
      rules configuration files are available in
      <filename>/usr/share/doc/udev-084/index.html</filename></para>
    </sect3>

    <sect3>
      <title>Module Loading</title>

      <para>If a device driver has been compiled as a module, the rules that
      LFS installs will cause <command>udevd</command> to call out to
      <command>/sbin/modprobe</command> with the name of the corresponding
      module, thereby loading the driver.</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 hotplug event. This hotplug event is then handled by
      <command>udevd</command> as described above.</para>
    </sect3>

    <!-- FIXME: These are questions Matt thought of while rewriting this page
         to reflect the hotplug-less setup but didn't have time to investigate
         straight away.
    <sect3>
      <title>Questions?</title>

      <para>7.4.2.3: Are default ownership/permissions still 0660 root:root?  I
      thought they'd changed, but can't be sure. Running without a config file
      will prove this pretty quickly.</para>

      <para>7.4.2.4: How does <command>udevd</command> know which driver to
      load, i.e. the correct module name?  Is it in the hotplug event?  I don't
      think it can be in /sys as that won't be populated yet (it's the driver
      itself that populates /sys, after all).</para>

      <para>Is the S05modules script still required?  If so, what are the use
      cases for it?</para>

    </sect3> -->

  </sect2>

  <sect2>
    <title>Problems with Creating Devices</title>

    <para>There are a few known problems when it comes to automatically creating
    device nodes:</para>

    <para>1) A kernel driver might 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. Udev will be unable to automatically create device nodes for such
    drivers. Create a static device node in
    <filename>/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 the
    <command>S10udev</command> bootscript.</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 role="nodump"><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>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>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>