diff options
Diffstat (limited to 'chapter07/udev.xml')
| -rw-r--r-- | chapter07/udev.xml | 229 |
1 files changed, 228 insertions, 1 deletions
diff --git a/chapter07/udev.xml b/chapter07/udev.xml index 73b90c419..51e001134 100644 --- a/chapter07/udev.xml +++ b/chapter07/udev.xml @@ -11,8 +11,235 @@ <primary sortas="a-Udev">Udev</primary> <secondary>usage</secondary></indexterm> +<para>In <xref linkend="chapter-building-system"/>, we installed the Udev +package. Before we go into the details regarding how this works, +a brief history of previous methods of handling devices is in +order.</para> -<para>See testing</para> +<para>Linux systems in general traditionally use a static device +creation method, whereby a great many device nodes are created under +<filename class="directory">/dev</filename> (sometimes literally +thousands of nodes), regardless of whether the corresponding hardware +devices actually exist. This is typically done via a +<command>MAKEDEV</command> script, which contains a number of +calls to the <command>mknod</command> program with the relevant major and minor device +numbers for every possible device that might exist in the world. Using +the udev method, only those devices which are detected by the kernel +get device nodes created for them. Because these device nodes will be +created each time the system boots, they will be stored on a +<systemitem class="filesystem">ramfs</systemitem> (a file system that +resides entirely in memory and does not take up any disk space). +Device nodes do not require much disk space, so the memory that is +used in negligable.</para> + +<sect2> +<title>History</title> + +<para>In February 2000, a new filesystem called <systemitem +class="filesystem">devfs</systemitem> was merged into the 2.3.46 +kernel and was made available during the 2.4 series of +stable kernels. Although it was present in the kernel source itself, +this method of creating devices dynamically never received +overwhelming support from the core kernel developers.</para> + +<para>The main problem with the approach adopted by <systemitem +class="filesystem">devfs</systemitem> was the way it handled +device detection, creation, and naming. The latter issue, that of +device node naming, was perhaps the most critical. It is generally +accepted that if device names are allowed to be configurable, then +the device naming policy should be up to a system administrator, not +imposed on them by any particular developer(s). The <systemitem +class="filesystem">devfs</systemitem> file system also suffers from race +conditions that are inherent in its design and cannot be fixed +without a substantial revision to the kernel. It has also been marked +as deprecated due to a lack of recent maintenance.</para> + +<para>With the development of the unstable 2.5 kernel tree, later +released as the 2.6 series of stable kernels, a new virtual filesystem +called <systemitem class="filesystem">sysfs</systemitem> came to be. +The job of <systemitem class="filesystem">sysfs</systemitem> is to +export a view of the system's structure to userspace processes. With +this userspace visible representation, the possibility of seeing a +userspace replacement for <systemitem +class="filesystem">devfs</systemitem> became much more +realistic.</para> +</sect2> + +<sect2> +<title>Udev Implementation</title> + +<para>The <systemitem class="filesystem">sysfs</systemitem> filesystem +was mentioned briefly above. One may wonder how <systemitem +class="filesystem">sysfs</systemitem> knows about the devices present +on a system and what device numbers should be used. Drivers that +have been compiled into the kernel directly register their objects +with <systemitem class="filesystem">sysfs</systemitem> as they are +detected by the kernel. For drivers compiled as modules, this will +happen when the module is loaded. Once the <systemitem +class="filesystem">sysfs</systemitem> filesystem is mounted (on +<filename class="directory">/sys</filename>), the data which the +built-in drivers registered with <systemitem +class="filesystem">sysfs</systemitem> are available to userspace +processes and to <command>udev</command> for device node creation.</para> + +<para>The <command>S10udev</command> initscript takes care of creating +these device nodes when Linux is booted. This script starts with +registering <command>/sbin/udev</command> as a hotplug event handler. +Hotplug events (discussed below) should not be generated during this +stage, but <command>udev</command> is registered just in case they do +occur. The <command>udevstart</command> program then walks through +the <systemitem class="filesystem">/sys</systemitem> filesystem and +creates devices under <filename class="directory">/dev</filename> that +match the descriptions. For example, +<filename>/sys/class/tty/vcs/dev</filename> contains the string +<quote>7:0</quote> This string is used by <command>udevstart</command> +to create <filename>/dev/vcs</filename> with major number +<emphasis>7</emphasis> and minor <emphasis>0</emphasis>. The +permissions of each and every device that <command>udevstart</command> +creates are set using files from the <filename +class="directory">/etc/udev.d/permissions.d/</filename> directory. +These are numbered in a similar fashion to the LFS bootscripts. If +<command>udev</command> cannot find a permissions file for the device +it is creating, it will default permissions to +<emphasis>600</emphasis> and ownership to +<emphasis>root:root</emphasis>. The names of the nodes created under +the <filename class="directory">/dev</filename> directory are +configured according to the rules specified in the files within the +<filename class="directory">/etc/udev/rules.d/</filename> +directory.</para> + +<para>Once the above stage is complete, all devices that were already +present and have compiled-in drivers will be available for use. What +about those devices that have modular drivers?</para> + +<para>Earlier, we mentioned the concept of a <quote>hotplug event +handler.</quote> When a new device connection is detected by the +kernel, the kernel will generate a hotplug event and look at the file +<filename>/proc/sys/kernel/hotplug</filename> to find out the +userspace program that handles the device's connection. The +<command>udev</command> initscript registered <command>udev</command> +as this handler. When these hotplug events are generated, the kernel +will tell <command>udev</command> to check the <filename +class="directory">/sys</filename> filesystem for the information +pertaining to this new device and create the <filename +class="directory">/dev</filename> entry for it.</para> + +<para>This brings us to one problem that exists with +<command>udev</command>, and likewise with <systemitem +class="filesystem">devfs</systemitem> before it. It is commonly +referred to as the <quote>chicken and egg</quote> problem. Most Linux +distrubtions handle loading modules via entries in +<filename>/etc/modules.conf</filename>. Access to a device node causes +the appropriate kernel module to load. With <command>udev</command>, +this method will not work because the device node does not exist until +the module is loaded. To solve this, the +<command>S05modules</command> bootscript was added to the +lfs-bootscripts package, along with the +<filename>/etc/sysconfig/modules</filename> file. By +adding module +names to the <filename>modules</filename> file, these modules will be +loaded when the computer is starting up. This allows +<command>udev</command> to detect the devices and create the +appropriate device nodes.</para> + +<para>Note that on slower machines or for drivers that create a lot +of device nodes, the process of creating devices may take a few +seconds to complete. This means that some device nodes may not be +immediately accessible.</para> +</sect2> + +<sect2> +<title>Handling Hotpluggable/Dynamic Devices</title> + +<para>When you plug in a device, such a Universal Serial Bus (USB) MP3 player, the kernel +recognizes that the device is now connected and generates a hotplug +event. If the driver is already loaded (either because it was compiled +into the kernel or because it was loaded via the +<command>S05modules</command> bootscript), <command>udev</command> will +be called upon to create the relevant device node(s) according to the +<systemitem class="filesystem">sysfs</systemitem> data available in +<filename class="directory">/sys</filename>. If the driver for the +just plugged in device is available as a module but currently unloaded, +then attaching the device to the system will only cause the kernel's +bus driver to generate a hotplug event that notifies userspace of the +new device connection and it not being attached to a driver. In +effect, nothing happens and the device itself is not usable +yet.</para> + +<para>If building a system that has a lot of drivers compiled as +modules rather than directly built into the kernel, using the +<command>S05modules</command> may not be practical. The Hotplug +package (see <ulink url="http://linux-hotplug.sourceforge.net/"/>) can +be beneficial in these cases. When the Hotplug package is installed, +it will respond to the aforementioned kernel's bus driver hotplug +events. The Hotplug package will load the appropriate module and make +this device available by creating the device node(s) for it.</para> +</sect2> + +<sect2> +<title>Problems with Creating Devices</title> + +<para>There are a few known problems when it comes to automatically creating +devices nodes:</para> + +<para>1) A kernel driver may not export its data to <systemitem +class="filesystem">sysfs</systemitem>.</para> + +<para>This is most common with third party drivers from outside the +kernel tree. These drivers will not end up having their device nodes +created. Use the +<filename>/etc/sysconfig/createfiles</filename> configuration file to +manually create the devices. Consult the +<filename>devices.txt</filename> file inside the kernel documentation +or the documentation for that driver to find the proper major/minor +numbers.</para> + +<para>2) A non-hardware device is required. This is most common with +the Advanced Linux Sound Architecture (ALSA) project's Open Sound +System (OSS) compatibility module. These types of devices can be +handled in one of two ways:</para> + +<itemizedlist> + +<listitem><para>Adding the module names to +<filename>/etc/sysconfig/modules</filename></para></listitem> +<listitem><para>Using an +<quote>install</quote> line in +<filename>/etc/modprobe.conf</filename>. This tells the +<command>modprobe</command> command <quote>when loading this module, +also load this other module, at the same time.</quote> For example:</para> + +<screen><userinput>install snd-pcm modprobe -i snd-pcm ; modprobe \ + snd-pcm-oss ; true</userinput></screen> + +<para>This will cause the system to load both the +<emphasis>snd-pcm</emphasis> and <emphasis>snd-pcm-oss</emphasis> +modules when any request is made to load the driver +<emphasis>snd-pcm</emphasis>.</para></listitem> +</itemizedlist> +</sect2> + +<sect2> +<title>Useful Reading</title> + +<para>Additional helpful documentation is available at the following +sites:</para> + +<itemizedlist> +<listitem><para remap="verbatim">A Userspace Implementation of devfs +<ulink url="http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf"><phrase +condition="pdf">http://www.kroah.com/linux/talks/ols_2003_udev_paper/ +Reprint-Kroah-Hartman-OLS2003.pdf</phrase></ulink></para></listitem> + +<listitem><para remap="verbatim">udev FAQ +<ulink url="http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ"/></para></listitem> + +<listitem><para remap="verbatim">The Linux Kernel Driver Model +<ulink url="http://public.planetmirror.com/pub/lca/2003/proceedings/papers/Patrick_Mochel/Patrick_Mochel.pdf"><phrase +condition="pdf">http://public.planetmirror.com/pub/lca/2003/proceedings/papers/ +Patrick_Mochel/Patrick_Mochel.pdf</phrase></ulink></para></listitem> +</itemizedlist> +</sect2> </sect1> |