source: chapter09/udev.xml@ 193913e

Last change on this file since 193913e was 193913e, checked in by Thomas Trepl (Moody) <thomas@…>, 10 months ago

First commit to add S6 as init system (like systemd)

  • Property mode set to 100644
File size: 15.8 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>Overview of Device and Module Handling</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 the udev
19 package when <phrase revision="sysv,s6">eudev</phrase>
20 <phrase revision="systemd">systemd</phrase> was built. Before we go into the
21 details regarding how this works, a brief history of previous methods of
22 handling devices is in order.</para>
24 <para>Linux systems in general traditionally used a static device creation
25 method, whereby a great many device nodes were created under <filename
26 class="directory">/dev</filename> (sometimes literally thousands of nodes),
27 regardless of whether the corresponding hardware devices actually existed. This
28 was typically done via a <command>MAKEDEV</command> script, which contains a
29 number of calls to the <command>mknod</command> program with the relevant
30 major and minor device numbers for every possible device that might exist in
31 the world.</para>
33 <para>Using the udev method, only those devices which are detected by the
34 kernel get device nodes created for them. Because these device nodes will be
35 created each time the system boots, they will be stored on a <systemitem
36 class="filesystem">devtmpfs</systemitem> file system (a virtual file system
37 that resides entirely in system memory). Device nodes do not require much
38 space, so the memory that is used is negligible.</para>
40 <sect2>
41 <title>History</title>
43 <para>In February 2000, a new filesystem called <systemitem
44 class="filesystem">devfs</systemitem> was merged into the 2.3.46 kernel
45 and was made available during the 2.4 series of stable kernels. Although
46 it was present in the kernel source itself, this method of creating devices
47 dynamically never received overwhelming support from the core kernel
48 developers.</para>
50 <para>The main problem with the approach adopted by <systemitem
51 class="filesystem">devfs</systemitem> was the way it handled device
52 detection, creation, and naming. The latter issue, that of device node
53 naming, was perhaps the most critical. It is generally accepted that if
54 device names are allowed to be configurable, then the device naming policy
55 should be up to a system administrator, not imposed on them by any
56 particular developer(s). The <systemitem
57 class="filesystem">devfs</systemitem> file system also suffered from race
58 conditions that were inherent in its design and could not be fixed without a
59 substantial revision to the kernel. It was marked as deprecated for a long
60 period &ndash; due to a lack of maintenance &ndash; and was finally removed
61 from the kernel in June, 2006.</para>
63 <para>With the development of the unstable 2.5 kernel tree, later released
64 as the 2.6 series of stable kernels, a new virtual filesystem called
65 <systemitem class="filesystem">sysfs</systemitem> came to be. The job of
66 <systemitem class="filesystem">sysfs</systemitem> is to export a view of
67 the system's hardware configuration to userspace processes. With this
68 userspace-visible representation, the possibility of developing a userspace
69 replacement for <systemitem class="filesystem">devfs</systemitem> became
70 much more realistic.</para>
72 </sect2>
74 <sect2>
75 <title>Udev Implementation</title>
77 <sect3>
78 <title>Sysfs</title>
80 <para>The <systemitem class="filesystem">sysfs</systemitem> filesystem
81 was mentioned briefly above. One may wonder how <systemitem
82 class="filesystem">sysfs</systemitem> knows about the devices present on
83 a system and what device numbers should be used for them. Drivers that
84 have been compiled into the kernel directly register their objects with a
85 <systemitem class="filesystem">sysfs</systemitem> (devtmpfs internally)
86 as they are detected by the kernel. For drivers compiled as modules, this
87 registration will happen when the module is loaded. Once the <systemitem
88 class="filesystem">sysfs</systemitem> filesystem is mounted (on /sys),
89 data which the drivers register with <systemitem
90 class="filesystem">sysfs</systemitem> are available to userspace
91 processes and to udevd for processing (including modifications to device
92 nodes).</para>
94 </sect3>
96 <sect3>
97 <title>Device Node Creation</title>
99 <para>Device files are created by the kernel by the <systemitem
100 class="filesystem">devtmpfs</systemitem> filesystem. Any driver that
101 wishes to register a device node will go through the <systemitem
102 class="filesystem">devtmpfs</systemitem> (via the driver core) to do it.
103 When a <systemitem class="filesystem">devtmpfs</systemitem> instance is
104 mounted on <filename class="directory">/dev</filename>, the device node
105 will initially be created with a fixed name, permissions, and
106 owner.</para>
108 <para>A short time later, the kernel will send a uevent to <command>
109 udevd</command>. Based on the rules specified in the files within the
110 <filename class="directory">/etc/udev/rules.d</filename>, <filename
111 class="directory">/usr/lib/udev/rules.d</filename>, and <filename
112 class="directory">/run/udev/rules.d</filename> directories, <command>
113 udevd</command> will create additional symlinks to the device node, or
114 change its permissions, owner, or group, or modify the internal
115 <command>udevd</command> database entry (name) for that object.</para>
117 <para>The rules in these three directories are numbered and all three
118 directories are merged together. If <command>udevd</command> can't find a
119 rule for the device it is creating, it will leave the permissions and
120 ownership at whatever <systemitem
121 class="filesystem">devtmpfs</systemitem> used initially.</para> </sect3>
123 <sect3 id="module-loading">
124 <title>Module Loading</title>
126 <para>Device drivers compiled as modules may have aliases built into them.
127 Aliases are visible in the output of the <command>modinfo</command>
128 program and are usually related to the bus-specific identifiers of devices
129 supported by a module. For example, the <emphasis>snd-fm801</emphasis>
130 driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801,
131 and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>.
132 For most devices, the bus driver exports the alias of the driver that
133 would handle the device via <systemitem
134 class="filesystem">sysfs</systemitem>. E.g., the
135 <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file
136 might contain the string
137 <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
138 The default rules provided with udev will cause <command>udevd</command>
139 to call out to <command>/sbin/modprobe</command> with the contents of the
140 <envar>MODALIAS</envar> uevent environment variable (which should be the
141 same as the contents of the <filename>modalias</filename> file in sysfs),
142 thus loading all modules whose aliases match this string after wildcard
143 expansion.</para>
145 <para>In this example, this means that, in addition to
146 <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted)
147 <emphasis>forte</emphasis> driver will be loaded if it is
148 available. See below for ways in which the loading of unwanted drivers can
149 be prevented.</para>
151 <para>The kernel itself is also able to load modules for network
152 protocols, filesystems, and NLS support on demand.</para>
154 </sect3>
156 <sect3>
157 <title>Handling Hotpluggable/Dynamic Devices</title>
159 <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3
160 player, the kernel recognizes that the device is now connected and
161 generates a uevent. This uevent is then handled by
162 <command>udevd</command> as described above.</para>
164 </sect3>
166 </sect2>
168 <sect2>
169 <title>Problems with Loading Modules and Creating Devices</title>
171 <para>There are a few possible problems when it comes to automatically
172 creating device nodes.</para>
174 <sect3>
175 <title>A kernel module is not loaded automatically</title>
177 <para>Udev will only load a module if it has a bus-specific alias and the
178 bus driver properly exports the necessary aliases to <systemitem
179 class="filesystem">sysfs</systemitem>. In other cases, one should
180 arrange module loading by other means. With Linux-&linux-version;, udev is
181 known to load properly-written drivers for INPUT, IDE, PCI, USB, SCSI,
182 SERIO, and FireWire devices.</para>
184 <para>To determine if the device driver you require has the necessary
185 support for udev, run <command>modinfo</command> with the module name as
186 the argument. Now try locating the device directory under
187 <filename class="directory">/sys/bus</filename> and check whether there is
188 a <filename>modalias</filename> file there.</para>
190 <para>If the <filename>modalias</filename> file exists in <systemitem
191 class="filesystem">sysfs</systemitem>, the driver supports the device and
192 can talk to it directly, but doesn't have the alias, it is a bug in the
193 driver. Load the driver without the help from udev and expect the issue
194 to be fixed later.</para>
196 <para>If there is no <filename>modalias</filename> file in the relevant
197 directory under <filename class="directory">/sys/bus</filename>, this
198 means that the kernel developers have not yet added modalias support to
199 this bus type. With Linux-&linux-version;, this is the case with ISA
200 busses. Expect this issue to be fixed in later kernel versions.</para>
202 <para>Udev is not intended to load <quote>wrapper</quote> drivers such as
203 <emphasis>snd-pcm-oss</emphasis> and non-hardware drivers such as
204 <emphasis>loop</emphasis> at all.</para>
206 </sect3>
208 <sect3>
209 <title>A kernel module is not loaded automatically, and udev is not
210 intended to load it</title>
212 <para>If the <quote>wrapper</quote> module only enhances the
213 functionality provided by some other module (e.g.,
214 <emphasis>snd-pcm-oss</emphasis> enhances the functionality of
215 <emphasis>snd-pcm</emphasis> by making the sound cards available to OSS
216 applications), configure <command>modprobe</command> to load the wrapper
217 after udev loads the wrapped module. To do this, add a
218 <quote>softdep</quote> line to the corresponding
219 <filename>/etc/modprobe.d/<replaceable>&lt;filename&gt;</replaceable>.conf</filename>
220 file. For example:</para>
222<screen role="nodump"><literal>softdep snd-pcm post: snd-pcm-oss</literal></screen>
224 <para>Note that the <quote>softdep</quote> command also allows
225 <literal>pre:</literal> dependencies, or a mixture of both
226 <literal>pre:</literal> and <literal>post:</literal> dependencies. See
227 the <filename>modprobe.d(5)</filename> manual page for more information
228 on <quote>softdep</quote> syntax and capabilities.</para>
230 <para revision="sysv,s6">If the module in question is not a wrapper and is
231 useful by itself, configure the <command>modules</command> bootscript to
232 load this module on system boot. To do this, add the module name to the
233 <filename>/etc/sysconfig/modules</filename> file on a separate line.
234 This works for wrapper modules too, but is suboptimal in that case.</para>
236 </sect3>
238 <sect3>
239 <title>Udev loads some unwanted module</title>
241 <para>Either don't build the module, or blacklist it in a
242 <filename>/etc/modprobe.d/blacklist.conf</filename> file as done with the
243 <emphasis>forte</emphasis> module in the example below:</para>
245<screen role="nodump"><literal>blacklist forte</literal></screen>
247 <para>Blacklisted modules can still be loaded manually with the
248 explicit <command>modprobe</command> command.</para>
250 </sect3>
252 <sect3>
253 <title>Udev creates a device incorrectly, or makes a wrong symlink</title>
255 <para>This usually happens if a rule unexpectedly matches a device. For
256 example, a poorly-written rule can match both a SCSI disk (as desired)
257 and the corresponding SCSI generic device (incorrectly) by vendor.
258 Find the offending rule and make it more specific, with the help of the
259 <command>udevadm info</command> command.</para>
261 </sect3>
263 <sect3>
264 <title>Udev rule works unreliably</title>
266 <para>This may be another manifestation of the previous problem. If not,
267 and your rule uses <systemitem class="filesystem">sysfs</systemitem>
268 attributes, it may be a kernel timing issue, to be fixed in later kernels.
269 For now, you can work around it by creating a rule that waits for the used
270 <systemitem class="filesystem">sysfs</systemitem> attribute and appending
271 it to the <filename>/etc/udev/rules.d/10-wait_for_sysfs.rules</filename>
272 file (create this file if it does not exist). Please notify the LFS
273 Development list if you do so and it helps.</para>
275 </sect3>
277 <sect3>
278 <title>Udev does not create a device</title>
280 <para>Further text assumes that the driver is built statically into the
281 kernel or already loaded as a module, and that you have already checked
282 that udev doesn't create a misnamed device.</para>
284 <para>Udev has no information needed to create a device node if a kernel
285 driver does not export its data to
286 <systemitem class="filesystem">sysfs</systemitem>. This is most common
287 with third party drivers from outside the kernel tree. Create a static
288 device node in <filename>/usr/lib/udev/devices</filename> with the
289 appropriate major/minor numbers (see the file
290 <filename>devices.txt</filename> inside the kernel documentation or the
291 documentation provided by the third party driver vendor). The static
292 device node will be copied to <filename class="directory">/dev</filename>
293 by <command>udev</command>.</para>
295 </sect3>
297 <sect3>
298 <title>Device naming order changes randomly after rebooting</title>
300 <para>This is due to the fact that udev, by design, handles uevents and
301 loads modules in parallel, and thus in an unpredictable order. This will
302 never be <quote>fixed</quote>. You should not rely upon the kernel device
303 names being stable. Instead, create your own rules that make symlinks with
304 stable names based on some stable attributes of the device, such as a
305 serial number or the output of various *_id utilities installed by udev.
306 See <xref linkend="ch-config-symlinks"/> and
307 <xref linkend="ch-config-network"/> for examples.</para>
309 </sect3>
311 </sect2>
313 <sect2>
314 <title>Useful Reading</title>
316 <para>Additional helpful documentation is available at the following
317 sites:</para>
319 <itemizedlist>
321 <listitem>
322 <para>A Userspace Implementation of <systemitem class="filesystem">devfs</systemitem>
323 <ulink url=""/></para>
324 </listitem>
326 <listitem>
327 <para>The <systemitem class="filesystem">sysfs</systemitem> Filesystem
328 <ulink url=""/></para>
329 </listitem>
331<!-- No longer available
332 <listitem>
333 <para>Pointers to further reading
334 <ulink url=""/>
335 </para>
336 </listitem>
338 </itemizedlist>
340 </sect2>
Note: See TracBrowser for help on using the repository browser.