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