Changeset d781ffb for chapter07/udev.xml


Ignore:
Timestamp:
12/18/2005 06:31:04 PM (18 years ago)
Author:
Manuel Canales Esparcia <manuel@…>
Branches:
10.0, 10.0-rc1, 10.1, 10.1-rc1, 11.0, 11.0-rc1, 11.0-rc2, 11.0-rc3, 11.1, 11.1-rc1, 11.2, 11.2-rc1, 11.3, 11.3-rc1, 12.0, 12.0-rc1, 12.1, 12.1-rc1, 6.3, 6.4, 6.5, 6.6, 6.7, 6.8, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.5-systemd, 7.6, 7.6-systemd, 7.7, 7.7-systemd, 7.8, 7.8-systemd, 7.9, 7.9-systemd, 8.0, 8.1, 8.2, 8.3, 8.4, 9.0, 9.1, arm, bdubbs/gcc13, ml-11.0, multilib, renodr/libudev-from-systemd, s6-init, trunk, xry111/arm64, xry111/arm64-12.0, xry111/clfs-ng, xry111/lfs-next, xry111/loongarch, xry111/loongarch-12.0, xry111/loongarch-12.1, xry111/mips64el, xry111/pip3, xry111/rust-wip-20221008, xry111/update-glibc
Children:
faaf88e
Parents:
b78c747
Message:

Chapter07 indentation.

git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@7230 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

File:
1 edited

Legend:

Unmodified
Added
Removed
  • chapter07/udev.xml

    rb78c747 rd781ffb  
    11<?xml version="1.0" encoding="ISO-8859-1"?>
    2 <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
     2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
     3  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
    34  <!ENTITY % general-entities SYSTEM "../general.ent">
    45  %general-entities;
    56]>
     7
    68<sect1 id="ch-scripts-udev">
    7 <title>Device and Module Handling on an LFS System</title>
    8 <?dbhtml filename="udev.html"?>
    9 
    10 <indexterm zone="ch-scripts-udev">
    11 <primary sortas="a-Udev">Udev</primary>
    12 <secondary>usage</secondary></indexterm>
    13 
    14 <para>In <xref linkend="chapter-building-system"/>, we installed the Udev
    15 package. Before we go into the details regarding how this works,
    16 a brief history of previous methods of handling devices is in
    17 order.</para>
    18 
    19 <para>Linux systems in general traditionally use a static device creation
    20 method, whereby a great many device nodes are created under <filename
    21 class="directory">/dev</filename> (sometimes literally thousands of nodes),
    22 regardless of whether the corresponding hardware devices actually exist. This is
    23 typically done via a <command>MAKEDEV</command> script, which contains a number
    24 of calls to the <command>mknod</command> program with the relevant major and
    25 minor device numbers for every possible device that might exist in the world.
    26 Using the Udev method, only those devices which are detected by the kernel get
    27 device nodes created for them. Because these device nodes will be created each
    28 time the system boots, they will be stored on a <systemitem
    29 class="filesystem">tmpfs</systemitem> file system (a virtual file system that
    30 resides entirely in system memory). Device nodes do not require much space, so
    31 the memory that is used is negligible.</para>
    32 
    33 <sect2>
    34 <title>History</title>
    35 
    36 <para>In February 2000, a new filesystem called <systemitem
    37 class="filesystem">devfs</systemitem> was merged into the 2.3.46
    38 kernel and was made available during the 2.4 series of
    39 stable kernels.  Although it was present in the kernel source itself,
    40 this method of creating devices dynamically never received
    41 overwhelming support from the core kernel developers.</para>
    42 
    43 <para>The main problem with the approach adopted by <systemitem
    44 class="filesystem">devfs</systemitem> was the way it handled
    45 device detection, creation, and naming. The latter issue, that of
    46 device node naming, was perhaps the most critical. It is generally
    47 accepted that if device names are allowed to be configurable, then
    48 the device naming policy should be up to a system administrator, not
    49 imposed on them by any particular developer(s). The <systemitem
    50 class="filesystem">devfs</systemitem> file system also suffers from race
    51 conditions that are inherent in its design and cannot be fixed
    52 without a substantial revision to the kernel. It has also been marked
    53 as deprecated due to a lack of recent maintenance.</para>
    54 
    55 <para>With the development of the unstable 2.5 kernel tree, later released as
    56 the 2.6 series of stable kernels, a new virtual filesystem called <systemitem
    57 class="filesystem">sysfs</systemitem> came to be. The job of <systemitem
    58 class="filesystem">sysfs</systemitem> is to export a view of the system's
    59 hardrware configuration to userspace processes. With this userspace-visible
    60 representation, the possibility of seeing a userspace replacement for
    61 <systemitem class="filesystem">devfs</systemitem> became much more
    62 realistic.</para>
    63 
    64 </sect2>
    65 
    66 <sect2>
    67 <title>Udev Implementation</title>
    68 
    69 <para>The <systemitem class="filesystem">sysfs</systemitem> filesystem was
    70 mentioned briefly above. One may wonder how <systemitem
    71 class="filesystem">sysfs</systemitem> knows about the devices present on a
    72 system and what device numbers should be used for them. Drivers that have been
    73 compiled into the kernel directly register their objects with <systemitem
    74 class="filesystem">sysfs</systemitem> as they are detected by the kernel. For
    75 drivers compiled as modules, this registration will happen when the module is
    76 loaded. Once the <systemitem class="filesystem">sysfs</systemitem> filesystem is
    77 mounted (on <filename class="directory">/sys</filename>), data which the
    78 built-in drivers registered with <systemitem
    79 class="filesystem">sysfs</systemitem> are available to userspace processes and
    80 to <command>udev</command> for device node creation.</para>
    81 
    82 <para>The <command>S10udev</command> initscript takes care of creating these
    83 device nodes when Linux is booted. This script starts by registering
    84 <command>/sbin/udevsend</command> as a hotplug event handler. Hotplug events
    85 (discussed below) are not usually generated during this stage, but
    86 <command>udev</command> is registered just in case they do occur. The
    87 <command>udevstart</command> program then walks through the <systemitem
    88 class="filesystem">/sys</systemitem> filesystem and creates devices under
    89 <filename class="directory">/dev</filename> that match the descriptions. For
    90 example, <filename>/sys/class/tty/vcs/dev</filename> contains the string
    91 <quote>7:0</quote> This string is used by <command>udevstart</command> to create
    92 <filename>/dev/vcs</filename> with major number <emphasis>7</emphasis> and minor
    93 <emphasis>0</emphasis>. The names and permissions of the nodes created under
    94 the <filename class="directory">/dev</filename> directory are configured
    95 according to the rules specified in the files within the <filename
    96 class="directory">/etc/udev/rules.d/</filename> directory. These are numbered in
    97 a similar fashion to the LFS-Bootscripts package. If <command>udev</command>
    98 can't find a rule for the device it is creating, it will default permissions to
    99 <emphasis>660</emphasis> and ownership to <emphasis>root:root</emphasis>.</para>
    100 
    101 <para>Once the above stage is complete, all devices that were already present
    102 and have compiled-in drivers will be available for use. This leads us to the
    103 devices that have modular drivers.</para>
    104 
    105 <para>Earlier, we mentioned the concept of a <quote>hotplug event
    106 handler.</quote> When a new device connection is detected by the kernel, the
    107 kernel will generate a hotplug event and look at the file
    108 <filename>/proc/sys/kernel/hotplug</filename> to determine the userspace program
    109 that handles the device's connection. The <command>udev</command> bootscript
    110 registered <command>udevsend</command> as this handler. When these hotplug
    111 events are generated, the kernel will tell <command>udev</command> to check the
    112 <filename class="directory">/sys</filename> filesystem for the information
    113 pertaining to this new device and create the <filename
    114 class="directory">/dev</filename> entry for it.</para>
    115 
    116 <para>This brings us to one problem that exists with <command>udev</command>,
    117 and likewise with <systemitem class="filesystem">devfs</systemitem> before it.
    118 It is commonly referred to as the <quote>chicken and egg</quote> problem. Most
    119 Linux distributions handle loading modules via entries in
    120 <filename>/etc/modules.conf</filename>. Access to a device node causes the
    121 appropriate kernel module to load. With <command>udev</command>, this method
    122 will not work because the device node does not exist until the module is loaded.
    123 To solve this, the <command>S05modules</command> bootscript was added to the
    124 LFS-Bootscripts package, along with the
    125 <filename>/etc/sysconfig/modules</filename> file. By adding module names to the
    126 <filename>modules</filename> file, these modules will be loaded when the
    127 computer starts up. This allows <command>udev</command> to detect the devices
    128 and create the appropriate device nodes.</para>
    129 
    130 <para>Note that on slower machines or for drivers that create a lot
    131 of device nodes, the process of creating devices may take a few
    132 seconds to complete. This means that some device nodes may not be
    133 immediately accessible.</para>
    134 </sect2>
    135 
    136 <sect2>
    137 <title>Handling Hotpluggable/Dynamic Devices</title>
    138 
    139 <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3 player, the kernel
    140 recognizes that the device is now connected and generates a hotplug
    141 event. If the driver is already loaded (either because it was compiled
    142 into the kernel or because it was loaded via the
    143 <command>S05modules</command> bootscript), <command>udev</command> will
    144 be called upon to create the relevant device node(s) according to the
    145 <systemitem class="filesystem">sysfs</systemitem> data available in
    146 <filename class="directory">/sys</filename>.</para>
    147 
    148 <para>If the driver for the just plugged in device is available as a module but
    149 currently unloaded, the Hotplug package will load the appropriate module
    150 and make this device available by creating the device node(s) for it.</para>
    151 </sect2>
    152 
    153 <sect2>
    154 <title>Problems with Creating Devices</title>
    155 
    156 <para>There are a few known problems when it comes to automatically creating
    157 device nodes:</para>
    158 
    159 <para>1) A kernel driver may not export its data to <systemitem
    160 class="filesystem">sysfs</systemitem>.</para>
    161    
    162 <para>This is most common with third party drivers from outside the kernel tree.
    163 Udev will be unable to automatically create device nodes for such drivers. Use
    164 the <filename>/etc/sysconfig/createfiles</filename> configuration file to
    165 manually create the devices. Consult the <filename>devices.txt</filename> file
    166 inside the kernel documentation or the documentation for that driver to find the
    167 proper major/minor numbers.</para>
    168 
    169 <para>2) A non-hardware device is required.  This is most common with
    170 the Advanced Linux Sound Architecture (ALSA) project's Open Sound
    171 System (OSS) compatibility module.  These types of devices can be
    172 handled in one of two ways:</para>
    173 
    174 <itemizedlist>
    175 
    176 <listitem><para>Adding the module names to
    177 <filename>/etc/sysconfig/modules</filename></para></listitem>
    178 <listitem><para>Using an
    179 <quote>install</quote> line in
    180 <filename>/etc/modprobe.conf</filename>. This tells the
    181 <command>modprobe</command> command <quote>when loading this module,
    182 also load this other module, at the same time.</quote>  For example:</para>
     9  <?dbhtml filename="udev.html"?>
     10
     11  <title>Device and Module Handling on an LFS System</title>
     12
     13  <indexterm zone="ch-scripts-udev">
     14    <primary sortas="a-Udev">Udev</primary>
     15    <secondary>usage</secondary>
     16  </indexterm>
     17
     18  <para>In <xref linkend="chapter-building-system"/>, we installed the Udev
     19  package. Before we go into the details regarding how this works,
     20  a brief history of previous methods of handling devices is in
     21  order.</para>
     22
     23  <para>Linux systems in general traditionally use a static device creation
     24  method, whereby a great many device nodes are created under <filename
     25  class="directory">/dev</filename> (sometimes literally thousands of nodes),
     26  regardless of whether the corresponding hardware devices actually exist. This is
     27  typically done via a <command>MAKEDEV</command> script, which contains a number
     28  of calls to the <command>mknod</command> program with the relevant major and
     29  minor device numbers for every possible device that might exist in the world.
     30  Using the Udev method, only those devices which are detected by the kernel get
     31  device nodes created for them. Because these device nodes will be created each
     32  time the system boots, they will be stored on a <systemitem
     33  class="filesystem">tmpfs</systemitem> file system (a virtual file system that
     34  resides entirely in system memory). Device nodes do not require much space, so
     35  the memory that is used is negligible.</para>
     36
     37  <sect2>
     38    <title>History</title>
     39
     40    <para>In February 2000, a new filesystem called <systemitem
     41    class="filesystem">devfs</systemitem> was merged into the 2.3.46 kernel
     42    and was made available during the 2.4 series of stable kernels. Although
     43    it was present in the kernel source itself, this method of creating devices
     44    dynamically never received overwhelming support from the core kernel
     45    developers.</para>
     46
     47    <para>The main problem with the approach adopted by <systemitem
     48    class="filesystem">devfs</systemitem> was the way it handled device
     49    detection, creation, and naming. The latter issue, that of device node
     50    naming, was perhaps the most critical. It is generally accepted that if
     51    device names are allowed to be configurable, then the device naming policy
     52    should be up to a system administrator, not imposed on them by any
     53    particular developer(s). The <systemitem class="filesystem">devfs</systemitem>
     54    file system also suffers from race conditions that are inherent in its design
     55    and cannot be fixed without a substantial revision to the kernel. It has also
     56    been marked as deprecated due to a lack of recent maintenance.</para>
     57
     58    <para>With the development of the unstable 2.5 kernel tree, later released as
     59    the 2.6 series of stable kernels, a new virtual filesystem called <systemitem
     60    class="filesystem">sysfs</systemitem> came to be. The job of <systemitem
     61    class="filesystem">sysfs</systemitem> is to export a view of the system's
     62    hardrware configuration to userspace processes. With this userspace-visible
     63    representation, the possibility of seeing a userspace replacement for
     64    <systemitem class="filesystem">devfs</systemitem> became much more
     65    realistic.</para>
     66
     67  </sect2>
     68
     69  <sect2>
     70    <title>Udev Implementation</title>
     71
     72    <para>The <systemitem class="filesystem">sysfs</systemitem> filesystem was
     73    mentioned briefly above. One may wonder how <systemitem
     74    class="filesystem">sysfs</systemitem> knows about the devices present on
     75    a system and what device numbers should be used for them. Drivers that have
     76    been compiled into the kernel directly register their objects with
     77    <systemitem class="filesystem">sysfs</systemitem> as they are detected by
     78    the kernel. For drivers compiled as modules, this registration will happen
     79    when the module is loaded. Once the <systemitem
     80    class="filesystem">sysfs</systemitem> filesystem is mounted (on <filename
     81    class="directory">/sys</filename>), data which the built-in drivers
     82    registered with <systemitem class="filesystem">sysfs</systemitem> are
     83    available to userspace processes and to <command>udev</command> for device
     84    node creation.</para>
     85
     86    <para>The <command>S10udev</command> initscript takes care of creating
     87    these device nodes when Linux is booted. This script starts by registering
     88    <command>/sbin/udevsend</command> as a hotplug event handler. Hotplug events
     89    (discussed below) are not usually generated during this stage, but
     90    <command>udev</command> is registered just in case they do occur. The
     91    <command>udevstart</command> program then walks through the <systemitem
     92    class="filesystem">/sys</systemitem> filesystem and creates devices under
     93    <filename class="directory">/dev</filename> that match the descriptions.
     94    For example, <filename>/sys/class/tty/vcs/dev</filename> contains the
     95    string <quote>7:0</quote> This string is used by <command>udevstart</command>
     96    to create <filename>/dev/vcs</filename> with major number
     97    <emphasis>7</emphasis> and minor <emphasis>0</emphasis>. The names and
     98    permissions of the nodes created under the <filename
     99    class="directory">/dev</filename> directory are configured according to the
     100    rules specified in the files within the <filename
     101    class="directory">/etc/udev/rules.d/</filename> directory. These are
     102    numbered in a similar fashion to the LFS-Bootscripts package. If
     103    <command>udev</command> can't find a rule for the device it is creating,
     104    it will default permissions to <emphasis>660</emphasis> and ownership to
     105    <emphasis>root:root</emphasis>.</para>
     106
     107    <para>Once the above stage is complete, all devices that were already present
     108    and have compiled-in drivers will be available for use. This leads us to the
     109    devices that have modular drivers.</para>
     110
     111    <para>Earlier, we mentioned the concept of a <quote>hotplug event
     112    handler.</quote> When a new device connection is detected by the kernel,
     113    the kernel will generate a hotplug event and look at the file
     114    <filename>/proc/sys/kernel/hotplug</filename> to determine the userspace
     115    program that handles the device's connection. The <command>udev</command>
     116    bootscript registered <command>udevsend</command> as this handler. When
     117    these hotplug events are generated, the kernel will tell
     118    <command>udev</command> to check the <filename
     119    class="directory">/sys</filename> filesystem for the information pertaining
     120    to this new device and create the <filename class="directory">/dev</filename>
     121    entry for it.</para>
     122
     123    <para>This brings us to one problem that exists with <command>udev</command>,
     124    and likewise with <systemitem class="filesystem">devfs</systemitem> before it.
     125    It is commonly referred to as the <quote>chicken and egg</quote> problem. Most
     126    Linux distributions handle loading modules via entries in
     127    <filename>/etc/modules.conf</filename>. Access to a device node causes the
     128    appropriate kernel module to load. With <command>udev</command>, this method
     129    will not work because the device node does not exist until the module is loaded.
     130    To solve this, the <command>S05modules</command> bootscript was added to the
     131    LFS-Bootscripts package, along with the
     132    <filename>/etc/sysconfig/modules</filename> file. By adding module names to the
     133    <filename>modules</filename> file, these modules will be loaded when the
     134    computer starts up. This allows <command>udev</command> to detect the devices
     135    and create the appropriate device nodes.</para>
     136
     137    <para>Note that on slower machines or for drivers that create a lot of device
     138    nodes, the process of creating devices may take a few seconds to complete.
     139    This means that some device nodes may not be immediately accessible.</para>
     140
     141  </sect2>
     142
     143  <sect2>
     144    <title>Handling Hotpluggable/Dynamic Devices</title>
     145
     146    <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3
     147    player, the kernel recognizes that the device is now connected and generates
     148    a hotplug event. If the driver is already loaded (either because it was
     149    compiled into the kernel or because it was loaded via the
     150    <command>S05modules</command> bootscript), <command>udev</command> will be
     151    called upon to create the relevant device node(s) according to the
     152    <systemitem class="filesystem">sysfs</systemitem> data available in
     153    <filename class="directory">/sys</filename>.</para>
     154
     155    <para>If the driver for the just plugged in device is available as a module but
     156    currently unloaded, the Hotplug package will load the appropriate module
     157    and make this device available by creating the device node(s) for it.</para>
     158
     159  </sect2>
     160
     161  <sect2>
     162    <title>Problems with Creating Devices</title>
     163
     164    <para>There are a few known problems when it comes to automatically creating
     165    device nodes:</para>
     166
     167    <para>1) A kernel driver may not export its data to <systemitem
     168    class="filesystem">sysfs</systemitem>.</para>
     169
     170    <para>This is most common with third party drivers from outside the kernel
     171    tree. Udev will be unable to automatically create device nodes for such
     172    drivers. Use the <filename>/etc/sysconfig/createfiles</filename>
     173    configuration file to manually create the devices. Consult the
     174    <filename>devices.txt</filename> file inside the kernel documentation or
     175    the documentation for that driver to find the proper major/minor
     176    numbers.</para>
     177
     178    <para>2) A non-hardware device is required.  This is most common with
     179    the Advanced Linux Sound Architecture (ALSA) project's Open Sound
     180    System (OSS) compatibility module.  These types of devices can be
     181    handled in one of two ways:</para>
     182
     183    <itemizedlist>
     184
     185      <listitem>
     186        <para>Adding the module names to
     187        <filename>/etc/sysconfig/modules</filename></para>
     188      </listitem>
     189
     190      <listitem>
     191        <para>Using an <quote>install</quote> line in
     192        <filename>/etc/modprobe.conf</filename>. This tells the
     193        <command>modprobe</command> command <quote>when loading this module,
     194        also load this other module, at the same time.</quote>
     195        For example:</para>
    183196
    184197<screen role="nodump"><userinput>install snd-pcm modprobe -i snd-pcm ; modprobe \
    185198    snd-pcm-oss ; true</userinput></screen>
    186199
    187 <para>This will cause the system to load both the
    188 <emphasis>snd-pcm</emphasis> and <emphasis>snd-pcm-oss</emphasis>
    189 modules when any request is made to load the driver
    190 <emphasis>snd-pcm</emphasis>.</para></listitem>
    191 </itemizedlist>
    192 </sect2>
    193 
    194 <sect2>
    195 <title>Useful Reading</title>
    196 
    197 <para>Additional helpful documentation is available at the following
    198 sites:</para>
    199 
    200 <itemizedlist>
    201 <listitem><para>A Userspace Implementation of <systemitem class="filesystem">devfs</systemitem>
    202 <ulink url="http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf"/></para></listitem>
    203 
    204 <listitem><para>udev FAQ
    205 <ulink url="http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ"/></para></listitem>
    206 
    207 <listitem><para>The Linux Kernel Driver Model
    208 <ulink url="http://public.planetmirror.com/pub/lca/2003/proceedings/papers/Patrick_Mochel/Patrick_Mochel.pdf"/></para></listitem>
    209 </itemizedlist>
    210 </sect2>
     200        <para>This will cause the system to load both the
     201        <emphasis>snd-pcm</emphasis> and <emphasis>snd-pcm-oss</emphasis>
     202        modules when any request is made to load the driver
     203        <emphasis>snd-pcm</emphasis>.</para>
     204      </listitem>
     205
     206    </itemizedlist>
     207
     208  </sect2>
     209
     210  <sect2>
     211    <title>Useful Reading</title>
     212
     213    <para>Additional helpful documentation is available at the following
     214    sites:</para>
     215
     216    <itemizedlist>
     217
     218      <listitem>
     219        <para>A Userspace Implementation of <systemitem class="filesystem">devfs</systemitem>
     220        <ulink url="http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf"/></para>
     221      </listitem>
     222
     223      <listitem>
     224        <para>udev FAQ
     225        <ulink url="http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ"/></para>
     226      </listitem>
     227
     228      <listitem>
     229        <para>The Linux Kernel Driver Model
     230        <ulink url="http://public.planetmirror.com/pub/lca/2003/proceedings/papers/Patrick_Mochel/Patrick_Mochel.pdf"/></para>
     231      </listitem>
     232
     233    </itemizedlist>
     234
     235  </sect2>
    211236
    212237</sect1>
    213 
Note: See TracChangeset for help on using the changeset viewer.