source: chapter07/udev.xml@ f6eeb801

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.4 7.5 7.5-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 f6eeb801 was f6eeb801, checked in by Bruce Dubbs <bdubbs@…>, 9 years ago

Another typo

git-svn-id: 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

  • Property mode set to 100644
File size: 17.9 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-scripts-udev">
9 <?dbhtml filename="udev.html"?>
11 <title>Device and Module Handling on an LFS System</title>
13 <indexterm zone="ch-scripts-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. 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>
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
27 is 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>
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>
39 <sect2>
40 <title>History</title>
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>
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 suffers from race
57 conditions that are inherent in its design and cannot 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>
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 seeing a userspace
68 replacement for <systemitem class="filesystem">devfs</systemitem> became
69 much more realistic.</para>
71 </sect2>
73 <sect2>
74 <title>Udev Implementation</title>
76 <sect3>
77 <title>Sysfs</title>
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>
93 </sect3>
95 <sect3>
96 <title>Device Node Creation</title>
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 <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>
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>
116 <para>The rules in these three directories are numbered in a similar
117 fashion to the LFS-Bootscripts package and all three directories are
118 merged together. If <command>udevd</command> can't find a rule for the
119 device it is creating, it will leave the permissions and ownership at
120 whatever <systemitem class="filesystem">devtmpfs</systemitem> used
121 initially.</para> </sect3>
123 <sect3>
124 <title>Udev Bootscripts</title>
126 <para>The first LFS bootscript,
127 <filename>/etc/init.d/mountvirtfs</filename> will copy any devices
128 located in <filename class="directory">/lib/udev/devices</filename> to
129 <filename class="directory">/dev</filename>. This is necessary because
130 some devices, directories, and symlinks are needed before the dynamic
131 device handling processes are available during the early stages of
132 booting a system, or are required by <command>udevd</command> itself.
133 Creating static device nodes in <filename
134 class="directory">/lib/udev/devices</filename> also provides an easy
135 workaround for devices that are not supported by the dynamic device
136 handling infrastructure.</para>
138 <para>The <filename>/etc/rc.d/init.d/udev</filename> initscript starts
139 <command>udevd</command>, triggers any "coldplug" devices that have
140 already been created by the kernel and waits for any rules to complete.
141 The script also unsets the uevent handler from the default of
142 <filename>/sbin/hotplug </filename>. This is done because the kernel no
143 longer needs to call out to an external binary. Instead
144 <command>udevd</command> will listen on a netlink socket for uevents that
145 the kernel raises.</para>
147 <para>The <command>/etc/rc.d/init.d/udev_retry</command> initscript takes
148 care of re-triggering events for subsystems whose rules may rely on
149 filesystems that are not mounted until the <command>mountfs</command>
150 script is run (in particular, <filename class="directory">/usr</filename>
151 and <filename class="directory">/var</filename> may cause this). This
152 script runs after the <command>mountfs</command> script, so those rules
153 (if re-triggered) should succeed the second time around. It is
154 configured from the <filename>/etc/sysconfig/udev_retry</filename> file;
155 any words in this file other than comments are considered subsystem names
156 to trigger at retry time. To find the subsystem of a device, use
157 <command>udevadm info --attribute-walk &lt;device&gt;</command> where
158 &lt;device&gt; is an absolute path in /dev or /sys such as /dev/sr0 or
159 /sys/class/rtc.</para>
161 </sect3>
163 <sect3>
164 <title>Module Loading</title>
166 <para>Device drivers compiled as modules may have aliases built into them.
167 Aliases are visible in the output of the <command>modinfo</command>
168 program and are usually related to the bus-specific identifiers of devices
169 supported by a module. For example, the <emphasis>snd-fm801</emphasis>
170 driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801,
171 and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>.
172 For most devices, the bus driver exports the alias of the driver that
173 would handle the device via <systemitem
174 class="filesystem">sysfs</systemitem>. E.g., the
175 <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file
176 might contain the string
177 <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
178 The default rules provided with Udev will cause <command>udevd</command>
179 to call out to <command>/sbin/modprobe</command> with the contents of the
180 <envar>MODALIAS</envar> uevent environment variable (which should be the
181 same as the contents of the <filename>modalias</filename> file in sysfs),
182 thus loading all modules whose aliases match this string after wildcard
183 expansion.</para>
185 <para>In this example, this means that, in addition to
186 <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted)
187 <emphasis>forte</emphasis> driver will be loaded if it is
188 available. See below for ways in which the loading of unwanted drivers can
189 be prevented.</para>
191 <para>The kernel itself is also able to load modules for network
192 protocols, filesystems and NLS support on demand.</para>
194 </sect3>
196 <sect3>
197 <title>Handling Hotpluggable/Dynamic Devices</title>
199 <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3
200 player, the kernel recognizes that the device is now connected and
201 generates a uevent. This uevent is then handled by
202 <command>udevd</command> as described above.</para>
204 </sect3>
206 </sect2>
208 <sect2>
209 <title>Problems with Loading Modules and Creating Devices</title>
211 <para>There are a few possible problems when it comes to automatically
212 creating device nodes.</para>
214 <sect3>
215 <title>A kernel module is not loaded automatically</title>
217 <para>Udev will only load a module if it has a bus-specific alias and the
218 bus driver properly exports the necessary aliases to <systemitem
219 class="filesystem">sysfs</systemitem>. In other cases, one should
220 arrange module loading by other means. With Linux-&linux-version;, Udev is
221 known to load properly-written drivers for INPUT, IDE, PCI, USB, SCSI,
222 SERIO, and FireWire devices.</para>
224 <para>To determine if the device driver you require has the necessary
225 support for Udev, run <command>modinfo</command> with the module name as
226 the argument. Now try locating the device directory under
227 <filename class="directory">/sys/bus</filename> and check whether there is
228 a <filename>modalias</filename> file there.</para>
230 <para>If the <filename>modalias</filename> file exists in <systemitem
231 class="filesystem">sysfs</systemitem>, the driver supports the device and
232 can talk to it directly, but doesn't have the alias, it is a bug in the
233 driver. Load the driver without the help from Udev and expect the issue
234 to be fixed later.</para>
236 <para>If there is no <filename>modalias</filename> file in the relevant
237 directory under <filename class="directory">/sys/bus</filename>, this
238 means that the kernel developers have not yet added modalias support to
239 this bus type. With Linux-&linux-version;, this is the case with ISA
240 busses. Expect this issue to be fixed in later kernel versions.</para>
242 <para>Udev is not intended to load <quote>wrapper</quote> drivers such as
243 <emphasis>snd-pcm-oss</emphasis> and non-hardware drivers such as
244 <emphasis>loop</emphasis> at all.</para>
246 </sect3>
248 <sect3>
249 <title>A kernel module is not loaded automatically, and Udev is not
250 intended to load it</title>
252 <para>If the <quote>wrapper</quote> module only enhances the functionality
253 provided by some other module (e.g., <emphasis>snd-pcm-oss</emphasis>
254 enhances the functionality of <emphasis>snd-pcm</emphasis> by making the
255 sound cards available to OSS applications), configure
256 <command>modprobe</command> to load the wrapper after Udev loads the
257 wrapped module. To do this, add a <quote>softdep</quote> line in any
258 <filename>/etc/modprobe.d/<replaceable>&lt;filename&gt;</replaceable>.conf</filename>
259 file. For example:</para>
261<screen role="nodump"><literal>softdep snd-pcm post: snd-pcm-oss</literal></screen>
263 <para>Note that the <quote>softdep</quote> command also allows
264 <literal>pre:</literal> dependencies, or a mixture of both
265 <literal>pre:</literal> and <literal>post:</literal>. See the
266 <filename>modprobe.d(5)</filename> manual page for more information
267 on <quote>softdep</quote> syntax and capabilities.</para>
269 <para>If the module in question is not a wrapper and is useful by itself,
270 configure the <command>modules</command> bootscript to load this
271 module on system boot. To do this, add the module name to the
272 <filename>/etc/sysconfig/modules</filename> file on a separate line.
273 This works for wrapper modules too, but is suboptimal in that case.</para>
275 </sect3>
277 <sect3>
278 <title>Udev loads some unwanted module</title>
280 <para>Either don't build the module, or blacklist it in a
281 <filename>/etc/modprobe.d/blacklist.conf</filename> file as done with the
282 <emphasis>forte</emphasis> module in the example below:</para>
284<screen role="nodump"><literal>blacklist forte</literal></screen>
286 <para>Blacklisted modules can still be loaded manually with the
287 explicit <command>modprobe</command> command.</para>
289 </sect3>
291 <sect3>
292 <title>Udev creates a device incorrectly, or makes a wrong symlink</title>
294 <para>This usually happens if a rule unexpectedly matches a device. For
295 example, a poorly-writen rule can match both a SCSI disk (as desired)
296 and the corresponding SCSI generic device (incorrectly) by vendor.
297 Find the offending rule and make it more specific, with the help of the
298 <command>udevadm info</command> command.</para>
300 </sect3>
302 <sect3>
303 <title>Udev rule works unreliably</title>
305 <para>This may be another manifestation of the previous problem. If not,
306 and your rule uses <systemitem class="filesystem">sysfs</systemitem>
307 attributes, it may be a kernel timing issue, to be fixed in later kernels.
308 For now, you can work around it by creating a rule that waits for the used
309 <systemitem class="filesystem">sysfs</systemitem> attribute and appending
310 it to the <filename>/etc/udev/rules.d/10-wait_for_sysfs.rules</filename>
311 file (create this file if it does not exist). Please notify the LFS
312 Development list if you do so and it helps.</para>
314 </sect3>
316 <sect3>
317 <title>Udev does not create a device</title>
319 <para>Further text assumes that the driver is built statically into the
320 kernel or already loaded as a module, and that you have already checked
321 that Udev doesn't create a misnamed device.</para>
323 <para>Udev has no information needed to create a device node if a kernel
324 driver does not export its data to <systemitem
325 class="filesystem">sysfs</systemitem>.
326 This is most common with third party drivers from outside the kernel
327 tree. Create a static device node in
328 <filename>/lib/udev/devices</filename> with the appropriate major/minor
329 numbers (see the file <filename>devices.txt</filename> inside the kernel
330 documentation or the documentation provided by the third party driver
331 vendor). The static device node will be copied to
332 <filename class="directory">/dev</filename> by the
333 <command>udev</command> bootscript.</para>
335 </sect3>
337 <sect3>
338 <title>Device naming order changes randomly after rebooting</title>
340 <para>This is due to the fact that Udev, by design, handles uevents and
341 loads modules in parallel, and thus in an unpredictable order. This will
342 never be <quote>fixed</quote>. You should not rely upon the kernel device
343 names being stable. Instead, create your own rules that make symlinks with
344 stable names based on some stable attributes of the device, such as a
345 serial number or the output of various *_id utilities installed by Udev.
346 See <xref linkend="ch-scripts-symlinks"/> and
347 <xref linkend="ch-scripts-network"/> for examples.</para>
349 </sect3>
351 </sect2>
353 <sect2>
354 <title>Useful Reading</title>
356 <para>Additional helpful documentation is available at the following
357 sites:</para>
359 <itemizedlist>
361 <listitem>
362 <para>A Userspace Implementation of <systemitem class="filesystem">devfs</systemitem>
363 <ulink url=""/></para>
364 </listitem>
366 <listitem>
367 <para>The <systemitem class="filesystem">sysfs</systemitem> Filesystem
368 <ulink url=""/></para>
369 </listitem>
371<!-- No longer available
372 <listitem>
373 <para>Pointers to further reading
374 <ulink url=""/>
375 </para>
376 </listitem>
378 </itemizedlist>
380 </sect2>
Note: See TracBrowser for help on using the repository browser.