source: BOOK/system-config/common/udev.xml @ d38577a

Last change on this file since d38577a was 7f8996d, checked in by William Harrington <kb0iic@…>, 10 years ago

Correction to previous commit, we want &linux-version2; entity where it is required. Do not use &linux-version; and &linux-version2; entities together. We just want Linux-3.14.10 where required, rather than LInux-3.14. And surely we do not want LInux-3.14-3.14.10.

  • Property mode set to 100644
File size: 15.3 KB
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3  "" [
4  <!ENTITY % general-entities SYSTEM "../../general.ent">
5  %general-entities;
8<sect1 id="ch-config-udev">
9  <?dbhtml filename="udev.html"?>
11  <title>Device and Module Handling on a CLFS System</title>
13  <indexterm zone="ch-config-udev">
14    <primary sortas="a-Udev">Udev</primary>
15    <secondary>usage</secondary>
16  </indexterm>
18  <para>In <xref linkend="chapter-building-system"/>, we installed Udev,
19  as one of the components of systemd. Before we go into the details regarding
20  how this works, a brief history of previous methods of handling devices is in
21  order.</para>
23  <sect2>
24    <title>History</title>
26    <sect3>
27      <title>Static Device Nodes</title>
29      <para>Linux systems in general traditionally use a static device creation
30      method, whereby a great many device nodes are created under <filename
31      class="directory">/dev</filename> (sometimes literally thousands of
32      nodes), regardless of whether the corresponding hardware devices actually
33      exist. This is typically done via a <command>MAKEDEV</command> script,
34      which contains a number of calls to the <command>mknod</command> program
35      with the relevant major and minor device numbers for every possible
36      device that might exist in the world.</para>
38    </sect3>
40    <sect3>
41      <title>Devfs</title>
43      <para>In February 2000, a new filesystem called <systemitem
44      class="filesystem">devfs</systemitem>, which dynamically created device
45      nodes as devices were found by the kernel, was merged into the
46      2.3.46 kernel and was made available during the 2.4 series of stable
47      kernels. Although it was present in the kernel source itself, this method
48      of creating devices dynamically never received overwhelming support from
49      the core kernel developers.</para>
51      <para>The main problem with the approach adopted by <systemitem
52      class="filesystem">devfs</systemitem> was the way it handled device
53      detection, creation, and naming. The latter issue, that of device node
54      naming, was perhaps the most critical. It is generally accepted that if
55      device names are allowed to be configurable, then the device naming policy
56      should be up to a system administrator, not imposed on them by any
57      particular developer(s). The <systemitem
58      class="filesystem">devfs</systemitem> file system also suffered from race
59      conditions that were inherent in its design and could not be fixed without
60      a substantial revision to the kernel. It was marked deprecated with the
61      release of the 2.6 kernel series, and was removed entirely as of version
62      2.6.18.</para>
64    </sect3>
66    <sect3>
67      <title>Sysfs</title>
69      <para>With the development of the unstable 2.5 kernel tree, later released
70      as the 2.6 series of stable kernels, a new virtual filesystem called
71      <systemitem class="filesystem">sysfs</systemitem> came to be. The job of
72      <systemitem class="filesystem">sysfs</systemitem> is to export a view of
73      the system's hardware configuration to userspace processes. Drivers that
74      have been compiled into the kernel directly register their objects with
75      <systemitem class="filesystem">sysfs</systemitem> as they are detected by
76      the kernel. For drivers compiled as modules, this registration will happen
77      when the module is loaded. Once the <systemitem
78      class="filesystem">sysfs</systemitem> filesystem is mounted (on <filename
79      class="directory">/sys</filename>), data which the built-in drivers
80      registered with <systemitem class="filesystem">sysfs</systemitem> are
81      available to userspace processes. With this userspace-visible
82      representation, the possibility of seeing a userspace replacement for
83      <systemitem class="filesystem">devfs</systemitem> became much more
84      realistic.</para>
86    </sect3>
88    <sect3>
89      <title>Udev Implementation</title>
91      <para>Shortly after the introduction of
92      <systemitem class="filesystem">sysfs</systemitem>, work began on a
93      program called Udev to advantage of it. The <command>udev</command>
94      daemon made calls to <function>mknod()</function> to create device nodes
95      in <filename class="directory">/dev</filename> dynamically, based on the
96      information from <systemitem class="filesystem">sysfs</systemitem>, in
97      <filename class="directory">/sys</filename>. For example,
98      <filename>/sys/class/tty/vcs/dev</filename> contains the string
99      <quote>7:0</quote>. This string was used by <command>udev</command>
100      to create a device node with major number <emphasis>7</emphasis> and
101      minor number <emphasis>0</emphasis>.</para>
103      <para>Linux kernel version 2.6.32 introduced a new virtual file system
104      called <systemitem class="filesystem">devtmpfs</systemitem>, an improved
105      replacement for <systemitem class="filesystem">devfs</systemitem>. This
106      allows device nodes to once again be dynamically created by the kernel,
107      without many of the problems of
108      <systemitem class="filesystem">devfs</systemitem>. As of version 176,
109      Udev no longer creates device nodes itself, instead relying on
110      <systemitem class="filesystem">devtmpfs</systemitem> to do so.</para>
112    </sect3>
114    <sect3>
115      <title>Systemd and Eudev</title>
117        <para>In 2010, development began on systemd, an alternate
118        <command>init</command> implementation. Starting with Udev 183, Udev's
119        source tree was merged with systemd. Several Gentoo
120        developers who disagreed with this merge announced a project fork
121        called Eudev in December 2012, created by extracting the
122        Udev code from systemd. One of the goals of Eudev is to allow for
123        easier installation and usage of <command>udevd</command> without
124        the need for the rest of systemd.</para>
125    </sect3>
127  </sect2>
129  <sect2>
130    <title>Device Node Creation</title>
132    <para>By default, device nodes created by the kernel in a
133    <systemitem class="filesystem">devtmpfs</systemitem> are owned by
134    <emphasis>root:root</emphasis> and have <emphasis>600</emphasis>
135    permissions. <command>udevd</command> can modify ownership and permissions
136    of the nodes under the <filename class="directory">/dev</filename>
137    directory, and can also create additional symlinks, based on rules
138    specified in the files within the
139    <filename class="directory">/etc/udev/rules.d</filename>,
140    <filename class="directory">/lib/udev/rules.d</filename>,
141    and <filename class="directory">/run/udev/rules.d</filename> directories.
142    The names for these files start with a number, to indicate the order in
143    which they are run, and they have a <filename>.rules</filename>
144    extension (<command>udevd</command> will ignore files with any other
145    extension). All of the rules files from these directories are combined into
146    a single list, sorted by filename, and run in that order. In the event of
147    a conflict, where a rules file with the same name exists in two or more of
148    these directories, the rules in <filename class="directory">/etc</filename>
149    take the highest priority, followed by rules files in
150    <filename class="directory">/run</filename>, and finally
151    <filename class="directory">/lib</filename>. Any device for which a rule
152    cannot be found will just be ignored by <command>udevd</command>
153    and be left at the defaults defined by the kernel, as described above. For
154    more details about writing Udev rules, see
155    <filename><ulink url="/usr/share/doc/systemd-&systemd-version;/udev.html"/></filename>.</para>
157  </sect2>
159  <sect2>
160    <title>Module Loading</title>
162    <para>Device drivers compiled as modules may have aliases built into them.
163    Aliases are visible in the output of the <command>modinfo</command>
164    program and are usually related to the bus-specific identifiers of devices
165    supported by a module. For example, the <emphasis>snd-fm801</emphasis>
166    driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801,
167    and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>.
168    For most devices, the bus driver exports the alias of the driver that
169    would handle the device via <systemitem
170    class="filesystem">sysfs</systemitem>. E.g., the
171    <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file
172    might contain the string
173    <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
174    The default rules provided by Udev will cause <command>udevd</command>
175    to call out to <command>/sbin/modprobe</command> with the contents of the
176    <envar>MODALIAS</envar> uevent environment variable (that should be the
177    same as the contents of the <filename>modalias</filename> file in sysfs),
178    thus loading all modules whose aliases match this string after wildcard
179    expansion.</para>
181    <para>In this example, this means that, in addition to
182    <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted)
183    <emphasis>forte</emphasis> driver will be loaded if it is
184    available. See below for ways in which the loading of unwanted drivers can
185    be prevented.</para>
187    <para>The kernel itself is also able to load modules for network
188    protocols, filesystems and NLS support on demand.</para>
190  </sect2>
192  <sect2>
193    <title>Problems with Loading Modules and Creating Devices</title>
195    <para>There are a few possible problems when it comes to automatically
196    creating device nodes.</para>
198    <sect3>
199      <title>A kernel module is not loaded automatically</title>
201      <para>Udev will only load a module if it has a bus-specific alias and the
202      bus driver properly exports the necessary aliases to <systemitem
203      class="filesystem">sysfs</systemitem>. In other cases, one should
204      arrange module loading by other means. With Linux-&linux-version2;, Udev
205      is known to load properly-written drivers for INPUT, IDE, PCI, USB, SCSI,
206      SERIO and FireWire devices.</para>
208      <para>To determine if the device driver you require has the necessary
209      support for Udev, run <command>modinfo</command> with the module name as
210      the argument.  Now try locating the device directory under
211      <filename class="directory">/sys/bus</filename> and check whether there is
212      a <filename>modalias</filename> file there.</para>
214      <para>If the <filename>modalias</filename> file exists in <systemitem
215      class="filesystem">sysfs</systemitem>, the driver supports the device and
216      can talk to it directly, but doesn't have the alias, it is a bug in the
217      driver. Load the driver without the help from Udev and expect the issue
218      to be fixed later.</para>
220      <para>If there is no <filename>modalias</filename> file in the relevant
221      directory under <filename class="directory">/sys/bus</filename>, this
222      means that the kernel developers have not yet added modalias support to
223      this bus type. With Linux-&linux-version2;, this is the
224      case with ISA busses. Expect this issue to be fixed in later kernel
225      versions.</para>
227      <para>Udev is not intended to load <quote>wrapper</quote> drivers such as
228      <emphasis>snd-pcm-oss</emphasis> and non-hardware drivers such as
229      <emphasis>loop</emphasis> at all.</para>
231    </sect3>
233    <sect3>
234      <title>A kernel module is not loaded automatically, and Udev is not
235      intended to load it</title>
237      <para>If the <quote>wrapper</quote> module only enhances the functionality
238      provided by some other module (e.g., <emphasis>snd-pcm-oss</emphasis>
239      enhances the functionality of <emphasis>snd-pcm</emphasis> by making the
240      sound cards available to OSS applications), configure
241      <command>modprobe</command> to load the wrapper after Udev loads the
242      wrapped module. To do this, add an <quote>install</quote> line to a file
243      in <filename>/etc/modprobe.d</filename>. For example:</para>
245<screen role="nodump"><literal>install snd-pcm /sbin/modprobe -i snd-pcm ; \
246    /sbin/modprobe snd-pcm-oss ; true</literal></screen>
248      <para>If the module in question is not a wrapper and is useful by itself,
249      configure the <command>S05modules</command> bootscript to load this
250      module on system boot. To do this, add the module name to the
251      <filename>/etc/sysconfig/modules</filename> file on a separate line.
252      This works for wrapper modules too, but is suboptimal in that case.</para>
254    </sect3>
256    <sect3>
257      <title>Udev loads some unwanted module</title>
259      <para>Either don't build the module, or blacklist it in
260      <filename>/etc/modprobe.d</filename> file as done with the
261      <emphasis>forte</emphasis> module in the example below:</para>
263<screen role="nodump"><literal>blacklist forte</literal></screen>
265      <para>Blacklisted modules can still be loaded manually with the
266      explicit <command>modprobe</command> command.</para>
268    </sect3>
270    <sect3>
271      <title>Udev makes a wrong symlink</title>
273      <para>This usually happens if a rule unexpectedly matches a device. For
274      example, a poorly-written rule can match both a SCSI disk (as desired)
275      and the corresponding SCSI generic device (incorrectly) by vendor.
276      Find the offending rule and make it more specific, with the help of
277      <command>udevadm info</command>.</para>
279    </sect3>
281    <sect3>
282      <title>Udev rule works unreliably</title>
284      <para>This may be another manifestation of the previous problem. If not,
285      and your rule uses <systemitem class="filesystem">sysfs</systemitem>
286      attributes, it may be a kernel timing issue, to be fixed in later kernels.
287      For now, you can work around it by creating a rule that waits for the used
288      <systemitem class="filesystem">sysfs</systemitem> attribute and appending
289      it to the <filename>/etc/udev/rules.d/10-wait_for_sysfs.rules</filename>
290      file. Please notify the CLFS Development list if you do so and it
291      helps.</para>
293    </sect3>
295    <sect3>
296      <title>Device naming order changes randomly after rebooting</title>
298      <para>This is due to the fact that Udev, by design, handles uevents and
299      loads modules in parallel, and thus in an unpredictable order. This will
300      never be <quote>fixed</quote>. You should not rely upon the kernel device
301      names being stable. Instead, create your own rules that make symlinks with
302      stable names based on some stable attributes of the device, such as a
303      serial number or the output of various *_id utilities installed by Udev.
304      See <xref linkend="ch-config-symlinks"/> and
305      <xref linkend="chapter-network"/> for examples.</para>
307    </sect3>
309  </sect2>
311  <sect2>
312    <title>Useful Reading</title>
314    <para>Additional helpful documentation is available at the following
315    sites:</para>
317    <itemizedlist>
319      <listitem>
320        <para remap="verbatim">A Userspace Implementation of <systemitem class="filesystem">devfs</systemitem>
321        <ulink url=""/></para>
322      </listitem>
324      <listitem>
325        <para remap="verbatim">The <systemitem class="filesystem">sysfs</systemitem> Filesystem
326        <ulink url=""/></para>
327      </listitem>
329    </itemizedlist>
331  </sect2>
Note: See TracBrowser for help on using the repository browser.