Changeset d2c332bc for chapter07/udev.xml
- Timestamp:
- 04/13/2006 06:45:33 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:
- a0d96d25
- Parents:
- dd7ed7b
- File:
-
- 1 edited
-
chapter07/udev.xml (modified) (3 diffs)
Legend:
- Unmodified
- Added
- Removed
-
chapter07/udev.xml
rdd7ed7b rd2c332bc 24 24 method, whereby a great many device nodes are created under <filename 25 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 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> 31 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 33 35 class="filesystem">tmpfs</systemitem> file system (a virtual file system that 34 36 resides entirely in system memory). Device nodes do not require much space, so … … 51 53 device names are allowed to be configurable, then the device naming policy 52 54 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> 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 has also been marked as deprecated 59 due to a lack of recent maintenance.</para> 60 61 <para>With the development of the unstable 2.5 kernel tree, later released 62 as the 2.6 series of stable kernels, a new virtual filesystem called 63 <systemitem class="filesystem">sysfs</systemitem> came to be. The job of 64 <systemitem class="filesystem">sysfs</systemitem> is to export a view of 65 the system's hardware configuration to userspace processes. With this 66 userspace-visible representation, the possibility of seeing a userspace 67 replacement for <systemitem class="filesystem">devfs</systemitem> became 68 much more realistic.</para> 66 69 67 70 </sect2> … … 70 73 <title>Udev Implementation</title> 71 74 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> 75 <sect3> 76 <title>Sysfs</title> 77 78 <para>The <systemitem class="filesystem">sysfs</systemitem> filesystem was 79 mentioned briefly above. One may wonder how <systemitem 80 class="filesystem">sysfs</systemitem> knows about the devices present on 81 a system and what device numbers should be used for them. Drivers that 82 have been compiled into the kernel directly register their objects with 83 <systemitem class="filesystem">sysfs</systemitem> as they are detected by 84 the kernel. For drivers compiled as modules, this registration will happen 85 when the module is loaded. Once the <systemitem 86 class="filesystem">sysfs</systemitem> filesystem is mounted (on <filename 87 class="directory">/sys</filename>), data which the built-in drivers 88 registered with <systemitem class="filesystem">sysfs</systemitem> are 89 available to userspace processes and to <command>udevd</command> for device 90 node creation.</para> 91 92 </sect3> 93 94 <sect3> 95 <title>Udev Bootscript</title> 96 97 <para>The <command>S10udev</command> initscript takes care of creating 98 device nodes when Linux is booted. The script starts by unsetting the 99 hotplug event handler from the default of <command>/sbin/hotplug</command> 100 This is done because, instead of the kernel calling out to an external 101 binary, <command>udevd</command> will listen on a netlink socket for 102 hotplug events that the kernel raises. The bootscript copies any static 103 device nodes that exist in <filename 104 class="directory">/lib/udev/devices</filename> to <filename 105 class="directory">/dev</filename>. This is necessary because some devices, 106 directories and symlinks are needed before the dynamic device handling 107 processes are available during the early stages of booting a system. 108 Creating static device nodes in 109 <filename class="directory">/lib/udev/devices</filename> also provides 110 an easy workaround for devices that are not supported by the dynamic 111 device handling infrastructure. The bootscript then starts the Udev 112 daemon, <command>udevd</command>, which will act on any hotplug events it 113 receives. Finally, the bootscript "coldplugs" any devices that 114 have already been registered with the kernel by forcing them to raise 115 hotplug events which <command>udevd</command> will then handle.</para> 116 117 </sect3> 118 119 <sect3> 120 <title>Device Node Creation</title> 121 122 <para>To obtain the right major and minor number for a device, Udev relies 123 on the information provided by <systemitem 124 class="filesystem">sysfs</systemitem> in <filename 125 class="directory">/sys</filename>. For example, 126 <filename>/sys/class/tty/vcs/dev</filename> contains the string 127 <quote>7:0</quote>. This string is used by <command>udevd</command> 128 to create a device node with major number <emphasis>7</emphasis> and minor 129 <emphasis>0</emphasis>. The names and permissions of the nodes created 130 under the <filename class="directory">/dev</filename> directory are 131 determined by rules specified in the files within the <filename 132 class="directory">/etc/udev/rules.d/</filename> directory. These are 133 numbered in a similar fashion to the LFS-Bootscripts package. If 134 <command>udevd</command> can't find a rule for the device it is creating, 135 it will default permissions to <emphasis>660</emphasis> and ownership to 136 <emphasis>root:root</emphasis>. Documentation on the syntax of the Udev 137 rules configuration files are available in 138 <filename>/usr/share/doc/udev-&udev-version;/index.html</filename></para> 139 140 </sect3> 141 142 <sect3> 143 <title>Module Loading</title> 144 145 <para>Device drivers compiled as modules may have aliases built into them. 146 Aliases are visible in the output of the <command>modinfo</command> 147 program and are usually related to the bus-specific identifiers of devices 148 supported by a module. For example, the <emphasis>snd-fm801</emphasis> 149 driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801, 150 and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>. 151 For most devices, the bus driver exports the alias of the driver that 152 would handle the device via <systemitem 153 class="filesystem">sysfs</systemitem>. E.g., the 154 <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file 155 might contain the string 156 <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>. 157 The rules that LFS installs will cause <command>udevd</command> to call 158 out to <command>/sbin/modprobe</command> with the contents of the 159 <envar>MODALIAS</envar> uevent environment variable (that should be the 160 same as the contents of the <filename>modalias</filename> file in sysfs), 161 thus loading all modules whose aliases match this string after wildcard 162 expansion.</para> 163 164 <para>In this example, this means that, in addition to 165 <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted) 166 <emphasis>forte</emphasis> driver will be loaded if it is 167 available. See below for ways in which the loading of unwanted drivers can 168 be prevented.</para> 169 170 <para>The kernel itself is also able to load modules for network 171 protocols, filesystems and NLS support on demand.</para> 172 173 </sect3> 174 175 <sect3> 176 <title>Handling Hotpluggable/Dynamic Devices</title> 177 178 <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3 179 player, the kernel recognizes that the device is now connected and 180 generates a hotplug event. This hotplug event is then handled by 181 <command>udevd</command> as described above.</para> 182 183 </sect3> 140 184 141 185 </sect2> 142 186 143 187 <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> 196 197 <screen role="nodump"><userinput>install snd-pcm modprobe -i snd-pcm ; modprobe \ 198 snd-pcm-oss ; true</userinput></screen> 199 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> 188 <title>Problems with Loading Modules and Creating Devices</title> 189 190 <para>There are a few possible problems when it comes to automatically 191 creating device nodes.</para> 192 193 <sect3> 194 <title>A kernel module is not loaded automatically</title> 195 196 <para>Udev will only load a module if it has a bus-specific alias and the 197 bus driver properly exports the necessary aliases to <systemitem 198 class="filesystem">sysfs</systemitem>. In other cases, one should 199 arrange module loading by other means. With Linux-&linux-version;, Udev is 200 known to load properly-written drivers for PCI, USB, SCSI, SERIO and 201 FireWire devices.</para> 202 203 <!-- After linux-2.6.16, add INPUT and IDE to the list above --> 204 205 <para>To determine if the device driver you require has the necessary 206 support for Udev, run <command>modinfo</command> with the module name as 207 the argument. Now try locating the device directory under 208 <filename class="directory">/sys/bus</filename> and check whether there is 209 a <filename>modalias</filename> file there.</para> 210 211 <para>If the <filename>modalias</filename> file exists in <systemitem 212 class="filesystem">sysfs</systemitem>, the driver supports the device and 213 can talk to it directly, but doesn't have the alias, it is a bug in the 214 driver. Load the driver without the help from Udev and expect the issue 215 to be fixed later.</para> 216 217 <para>If there is no <filename>modalias</filename> file in the relevant 218 directory under <filename class="directory">/sys/bus</filename>, this 219 means that the kernel developers have not yet added modalias support to 220 this bus type. With Linux-&linux-version;, this is the case with ISA and 221 IDE busses. Expect this issue to be fixed in later kernel versions.</para> 222 223 <!-- Remove IDE from the list above after Linux-2.6.16 --> 224 225 <para>Udev is not intended to load <quote>wrapper</quote> drivers such as 226 <emphasis>snd-pcm-oss</emphasis> and non-hardware drivers such as 227 <emphasis>loop</emphasis> at all.</para> 228 229 </sect3> 230 231 <sect3> 232 <title>A kernel module is not loaded automatically, and Udev is not 233 intended to load it</title> 234 235 <para>If the <quote>wrapper</quote> module only enhances the functionality 236 provided by some other module (e.g., <emphasis>snd-pcm-oss</emphasis> 237 enhances the functionality of <emphasis>snd-pcm</emphasis> by making the 238 sound cards available to OSS applications), configure 239 <command>modprobe</command> to load the wrapper after Udev loads the 240 wrapped module. To do this, add an <quote>install</quote> line in 241 <filename>/etc/modprobe.conf</filename>. For example:</para> 242 243 <screen role="nodump"><literal>install snd-pcm modprobe -i snd-pcm ; modprobe \ 244 snd-pcm-oss ; true</literal></screen> 245 246 <para>If the module in question is not a wrapper and is useful by itself, 247 configure the <command>S05modules</command> bootscript to load this 248 module on system boot. To do this, add the module name to the 249 <filename>/etc/sysconfig/modules</filename> file on a separate line. 250 This works for wrapper modules too, but is suboptimal in that case.</para> 251 252 </sect3> 253 254 <sect3> 255 <title>Udev loads some unwanted module</title> 256 257 <para>Either don't build the module, or blacklist it in 258 <filename>/etc/modprobe.conf</filename> file as done with the 259 <emphasis>forte</emphasis> module in the example below:</para> 260 261 <screen role="nodump"><literal>blacklist forte</literal></screen> 262 263 <para>Blacklisted modules can still be loaded manually with the 264 explicit <command>modprobe</command> command.</para> 265 266 </sect3> 267 268 <sect3> 269 <title>Udev creates a device incorrectly, or makes a wrong symlink</title> 270 271 <para>This usually happens if a rule unexpectedly matches a device. For 272 example, a poorly-writen rule can match by both a SCSI disk (as desired) 273 and the corresponding SCSI generic device (incorrectly) by vendor. 274 Increase the logging verbosity of Udev, find the offending rule by 275 examining the logs and make it more specific.</para> 276 277 </sect3> 278 279 <sect3> 280 <title>Udev rule works unreliably</title> 281 282 <para>This may be another manifestation of the previous problem. If not, 283 and your rule uses <systemitem class="filesystem">sysfs</systemitem> 284 attributes, it may be a kernel timing issue, to be fixed in later kernels. 285 For now, you can work around it by creating a rule that waits for the used 286 <systemitem class="filesystem">sysfs</systemitem> attribute and appending 287 it to the <filename>/etc/udev/rules.d/10-wait_for_sysfs.rules</filename> 288 file. Please notify the LFS Development list if you do so and it 289 helps.</para> 290 291 </sect3> 292 293 <sect3> 294 <title>Udev does not create a device</title> 295 296 <para>Further text assumes that the driver is built statically into the 297 kernel or already loaded as a module, and that you have already checked 298 that Udev doesn't create a misnamed device.</para> 299 300 <para>Udev has no information needed to create a device node if a kernel 301 driver does not export its data to <systemitem 302 class="filesystem">sysfs</systemitem>. 303 This is most common with third party drivers from outside the kernel 304 tree. Create a static device node in 305 <filename>/lib/udev/devices</filename> with the appropriate major/minor 306 numbers (see the file <filename>devices.txt</filename> inside the kernel 307 documentation or the documentation provided by the third party driver 308 vendor). The static device node will be copied to 309 <filename class="directory">/dev</filename> by the 310 <command>S10udev</command> bootscript.</para> 311 312 </sect3> 313 314 <sect3> 315 <title>Device naming order changes randomly after rebooting</title> 316 317 <para>This is due to the fact that Udev, by design, handles uevents and 318 loads modules in parallel, and thus in an unpredictable order. This will 319 never be <quote>fixed</quote>. You should not rely upon the kernel device 320 names being stable. Instead, create your own rules that make symlinks with 321 stable names based on some stable attributes of the device, such as a 322 serial number or the output of various *_id utilities installed by Udev. 323 See also the network interface renaming example in 324 <xref linkend="ch-scripts-network"/>.</para> 325 326 </sect3> 207 327 208 328 </sect2>
Note:
See TracChangeset
for help on using the changeset viewer.
