source: chapter07/udev.xml@ 1684855

Last change on this file since 1684855 was a4495da, checked in by Jim Gifford <jim@…>, 19 years ago

Text updates from Matt

git-svn-id: http://svn.linuxfromscratch.org/LFS/branches/multi-arch/BOOK@4993 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

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