source: chapter07/udev.xml@ bf58c1e

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 7.10 7.10-rc1 7.6 7.6-rc1 7.7 7.7-rc1 7.8 7.8-rc1 7.9 7.9-rc1 7.9-rc2 8.0 8.0-rc1 8.1 8.1-rc1 8.1-rc2 8.2 8.2-rc1 8.3 8.3-rc1 8.3-rc2 8.4 8.4-rc1 9.0 9.0-rc1 9.1 9.1-rc1 BOOK.old arm cross-chap5 hybrid ml-11.0 multilib nosym old-trunk trunk xry111/clfs-ng xry111/git-transition xry111/glibc-2.34 xry111/lfs-next xry111/tester-nohack xry111/usr-move
Last change on this file since bf58c1e was bf58c1e, checked in by Bruce Dubbs <bdubbs@…>, 8 years ago

Rewrite and reorganize Chapter 7.
Update systemd customization.

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

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