From 81fd230419b0cfd052b08fc1ed352bb7d49975df Mon Sep 17 00:00:00 2001 From: Gerard Beekmans Date: Sat, 19 Feb 2005 22:16:42 +0000 Subject: Trunk is now identical to Testing git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@4648 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689 --- chapter07/udev.xml | 229 ++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 228 insertions(+), 1 deletion(-) (limited to 'chapter07/udev.xml') 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 @@ Udev usage +In , 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. -See testing +Linux systems in general traditionally use a static device +creation method, whereby a great many device nodes are created under +/dev (sometimes literally +thousands of nodes), regardless of whether the corresponding hardware +devices actually exist. This is typically done via a +MAKEDEV script, which contains a number of +calls to the mknod 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 +ramfs (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. + + +History + +In February 2000, a new filesystem called devfs 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. + +The main problem with the approach adopted by devfs 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 devfs 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. + +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 sysfs came to be. +The job of sysfs 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 devfs became much more +realistic. + + + +Udev Implementation + +The sysfs filesystem +was mentioned briefly above. One may wonder how sysfs 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 sysfs as they are +detected by the kernel. For drivers compiled as modules, this will +happen when the module is loaded. Once the sysfs filesystem is mounted (on +/sys), the data which the +built-in drivers registered with sysfs are available to userspace +processes and to udev for device node creation. + +The S10udev initscript takes care of creating +these device nodes when Linux is booted. This script starts with +registering /sbin/udev as a hotplug event handler. +Hotplug events (discussed below) should not be generated during this +stage, but udev is registered just in case they do +occur. The udevstart program then walks through +the /sys filesystem and +creates devices under /dev that +match the descriptions. For example, +/sys/class/tty/vcs/dev contains the string +7:0 This string is used by udevstart +to create /dev/vcs with major number +7 and minor 0. The +permissions of each and every device that udevstart +creates are set using files from the /etc/udev.d/permissions.d/ directory. +These are numbered in a similar fashion to the LFS bootscripts. If +udev cannot find a permissions file for the device +it is creating, it will default permissions to +600 and ownership to +root:root. The names of the nodes created under +the /dev directory are +configured according to the rules specified in the files within the +/etc/udev/rules.d/ +directory. + +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? + +Earlier, we mentioned the concept of a hotplug event +handler. When a new device connection is detected by the +kernel, the kernel will generate a hotplug event and look at the file +/proc/sys/kernel/hotplug to find out the +userspace program that handles the device's connection. The +udev initscript registered udev +as this handler. When these hotplug events are generated, the kernel +will tell udev to check the /sys filesystem for the information +pertaining to this new device and create the /dev entry for it. + +This brings us to one problem that exists with +udev, and likewise with devfs before it. It is commonly +referred to as the chicken and egg problem. Most Linux +distrubtions handle loading modules via entries in +/etc/modules.conf. Access to a device node causes +the appropriate kernel module to load. With udev, +this method will not work because the device node does not exist until +the module is loaded. To solve this, the +S05modules bootscript was added to the +lfs-bootscripts package, along with the +/etc/sysconfig/modules file. By +adding module +names to the modules file, these modules will be +loaded when the computer is starting up. This allows +udev to detect the devices and create the +appropriate device nodes. + +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. + + + +Handling Hotpluggable/Dynamic Devices + +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 +S05modules bootscript), udev will +be called upon to create the relevant device node(s) according to the +sysfs data available in +/sys. 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. + +If building a system that has a lot of drivers compiled as +modules rather than directly built into the kernel, using the +S05modules may not be practical. The Hotplug +package (see ) 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. + + + +Problems with Creating Devices + +There are a few known problems when it comes to automatically creating +devices nodes: + +1) A kernel driver may not export its data to sysfs. + +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 +/etc/sysconfig/createfiles configuration file to +manually create the devices. Consult the +devices.txt file inside the kernel documentation +or the documentation for that driver to find the proper major/minor +numbers. + +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: + + + +Adding the module names to +/etc/sysconfig/modules +Using an +install line in +/etc/modprobe.conf. This tells the +modprobe command when loading this module, +also load this other module, at the same time. For example: + +install snd-pcm modprobe -i snd-pcm ; modprobe \ + snd-pcm-oss ; true + +This will cause the system to load both the +snd-pcm and snd-pcm-oss +modules when any request is made to load the driver +snd-pcm. + + + + +Useful Reading + +Additional helpful documentation is available at the following +sites: + + +A Userspace Implementation of devfs +http://www.kroah.com/linux/talks/ols_2003_udev_paper/ +Reprint-Kroah-Hartman-OLS2003.pdf + +udev FAQ + + +The Linux Kernel Driver Model +http://public.planetmirror.com/pub/lca/2003/proceedings/papers/ +Patrick_Mochel/Patrick_Mochel.pdf + + -- cgit v1.2.3-54-g00ecf