Changeset d46b6ed for BOOK/system-config/common
- Timestamp:
- May 21, 2014, 4:34:11 PM (10 years ago)
- Branches:
- clfs-3.0.0-systemd, master, systemd
- Children:
- 9224712
- Parents:
- fab5058
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
BOOK/system-config/common/udev.xml
rfab5058 rd46b6ed 12 12 13 13 <indexterm zone="ch-scripts-udev"> 14 <primary sortas="a- systemd">Systemd</primary>15 <secondary>u dev usage</secondary>14 <primary sortas="a-Udev">Udev</primary> 15 <secondary>usage</secondary> 16 16 </indexterm> 17 17 18 <para>In <xref linkend="chapter-building-system"/>, we installed systemd, 19 which contains systemd-udevd, previously known as Udev. Before we go into 20 the details regarding how this works, a brief history of previous methods of 21 handling devices is in 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 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 35 class="filesystem">tmpfs</systemitem> file system (a virtual file system that 36 resides entirely in system memory). Device nodes do not require much space, so 37 the memory that is used is negligible.</para> 18 <para>In <xref linkend="chapter-building-system"/>, we installed Udev, 19 as one of the components of systemd. Before we go into the details regarding 20 how this works, a brief history of previous methods of handling devices is in 21 order.</para> 38 22 39 23 <sect2> 40 24 <title>History</title> 41 25 42 <para>In February 2000, a new filesystem called <systemitem 43 class="filesystem">devfs</systemitem> was merged into the 2.3.46 kernel 44 and was made available during the 2.4 series of stable kernels. Although 45 it was present in the kernel source itself, this method of creating devices 46 dynamically never received overwhelming support from the core kernel 47 developers.</para> 48 49 <para>The main problem with the approach adopted by <systemitem 50 class="filesystem">devfs</systemitem> was the way it handled device 51 detection, creation, and naming. The latter issue, that of device node 52 naming, was perhaps the most critical. It is generally accepted that if 53 device names are allowed to be configurable, then the device naming policy 54 should be up to a system administrator, not imposed on them by any 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> 69 70 </sect2> 71 72 <sect2> 73 <title>Udev Implementation</title> 26 <sect3> 27 <title>Static Device Nodes</title> 28 29 <para>Linux systems in general traditionally use a static device creation 30 method, whereby a great many device nodes are created under <filename 31 class="directory">/dev</filename> (sometimes literally thousands of nodes), 32 regardless of whether the corresponding hardware devices actually exist. 33 This is typically done via a <command>MAKEDEV</command> script, which 34 contains a number of calls to the <command>mknod</command> program with the 35 relevant major and minor device numbers for every possible device that 36 might exist in the world.</para> 37 38 </sect3> 39 40 <sect3> 41 <title>Devfs</title> 42 43 <para>In February 2000, a new filesystem called <systemitem 44 class="filesystem">devfs</systemitem> was merged into the 2.3.46 kernel 45 and was made available during the 2.4 series of stable kernels. Although 46 it was present in the kernel source itself, this method of creating devices 47 dynamically never received overwhelming support from the core kernel 48 developers.</para> 49 50 <para>The main problem with the approach adopted by <systemitem 51 class="filesystem">devfs</systemitem> was the way it handled device 52 detection, creation, and naming. The latter issue, that of device node 53 naming, was perhaps the most critical. It is generally accepted that if 54 device names are allowed to be configurable, then the device naming policy 55 should be up to a system administrator, not imposed on them by any 56 particular developer(s). The <systemitem 57 class="filesystem">devfs</systemitem> file system also suffered from race 58 conditions that were inherent in its design and could not be fixed without a 59 substantial revision to the kernel. It was marked deprecated with the 60 release of the 2.6 kernel series, and was removed entirely as of version 61 2.6.18.</para> 62 63 </sect3> 74 64 75 65 <sect3> 76 66 <title>Sysfs</title> 77 67 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 68 <para>With the development of the unstable 2.5 kernel tree, later released 69 as the 2.6 series of stable kernels, a new virtual filesystem called 70 <systemitem class="filesystem">sysfs</systemitem> came to be. The job of 71 <systemitem class="filesystem">sysfs</systemitem> is to export a view of 72 the system's hardware configuration to userspace processes. Drivers that 82 73 have been compiled into the kernel directly register their objects with 83 74 <systemitem class="filesystem">sysfs</systemitem> as they are detected by … … 87 78 class="directory">/sys</filename>), data which the built-in drivers 88 79 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>Device Node Creation</title> 96 97 <para>To obtain the right major and minor number for a device, Udev relies 98 on the information provided by <systemitem 99 class="filesystem">sysfs</systemitem> in <filename 100 class="directory">/sys</filename>. For example, 80 available to userspace processes. With this 81 userspace-visible representation, the possibility of seeing a userspace 82 replacement for <systemitem class="filesystem">devfs</systemitem> became 83 much more realistic.</para> 84 85 </sect3> 86 87 <sect3> 88 <title>Udev Implementation</title> 89 90 <!-- <title>Device Node Creation</title> --> 91 92 <para>When Udev was introduced, the <command>udevd</command> daemon made 93 calls to mknod() to create device nodes in 94 <filename class="directory">/dev</filename> dynamically, based on the 95 information from <systemitem class="filesystem">sysfs</systemitem>, in 96 <filename class="directory">/sys</filename>. For example, 101 97 <filename>/sys/class/tty/vcs/dev</filename> contains the string 102 <quote>7:0</quote>. This string is used by <command>udevd</command> 103 to create a device node with major number <emphasis>7</emphasis> and minor 104 <emphasis>0</emphasis>. The names and permissions of the nodes created 105 under the <filename class="directory">/dev</filename> directory are 106 determined by rules specified in the files within the 107 <filename class="directory">/lib/udev/rules.d</filename> and <filename 108 class="directory">/etc/udev/rules.d/</filename> directories. These files 109 have names that start with numbers, and are evaluated in numerical order. 110 If <command>udevd</command> can't find a rule for the device it is 111 creating, it will default permissions to <emphasis>660</emphasis> and 112 ownership to <emphasis>root:root</emphasis>. </para> 113 114 </sect3> 115 116 <sect3> 117 <title>Module Loading</title> 118 119 <para>Device drivers compiled as modules may have aliases built into them. 120 Aliases are visible in the output of the <command>modinfo</command> 121 program and are usually related to the bus-specific identifiers of devices 122 supported by a module. For example, the <emphasis>snd-fm801</emphasis> 123 driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801, 124 and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>. 125 For most devices, the bus driver exports the alias of the driver that 126 would handle the device via <systemitem 127 class="filesystem">sysfs</systemitem>. E.g., the 128 <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file 129 might contain the string 130 <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>. 131 The default rules provided by Udev will cause <command>udevd</command> 132 to call out to <command>/sbin/modprobe</command> with the contents of the 133 <envar>MODALIAS</envar> uevent environment variable (that should be the 134 same as the contents of the <filename>modalias</filename> file in sysfs), 135 thus loading all modules whose aliases match this string after wildcard 136 expansion.</para> 137 138 <para>In this example, this means that, in addition to 139 <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted) 140 <emphasis>forte</emphasis> driver will be loaded if it is 141 available. See below for ways in which the loading of unwanted drivers can 142 be prevented.</para> 143 144 <para>The kernel itself is also able to load modules for network 145 protocols, filesystems and NLS support on demand.</para> 146 147 </sect3> 148 149 <sect3> 150 <title>Handling Hotpluggable/Dynamic Devices</title> 151 152 <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3 153 player, the kernel recognizes that the device is now connected and 154 generates a uevent. This uevent is then handled by 155 <command>udevd</command> as described above.</para> 156 157 </sect3> 98 <quote>7:0</quote>. This string was used by <command>udevd</command> 99 to create a device node with major number <emphasis>7</emphasis> and 100 minor number <emphasis>0</emphasis>. Using the Udev method 101 only those devices which are detected by the kernel would get device 102 nodes created for them. Because these device nodes were created each time 103 the system boots, they were stored on a 104 <systemitem class="filesystem">tmpfs</systemitem> file system (a virtual 105 file system that resides entirely in system memory). Device nodes do not 106 require much space, so the memory that is used is negligible.</para> 107 108 <para>Linux kernel version 2.6.32 introduced a new virtual file system 109 called <systemitem class="filesystem">devtmpfs</systemitem>, a 110 replacement for <systemitem class="filesystem">devfs</systemitem>. 111 With this approach, a 112 <systemitem class="filesystem">devtmpfs</systemitem> file system is 113 mounted on <filename class="directory">/dev/</filename> when the system 114 is booted, and all needed device nodes are created on this virtual 115 file system. As of version 176, Udev no longer creates device nodes 116 itself, instead relying on 117 <systemitem class="filesystem">devtmpfs</systemitem> to do so.</para> 118 119 <para>Udev also sets appropriate ownership and permissions 120 for the device nodes, and creates extra symlinks as needed (such as 121 <filename class="symlink">/dev/cdrom</filename>). The ownership and 122 permissions of the nodes under the 123 <filename class="directory">/dev</filename> directory are 124 determined by rules specified in the files within the <filename 125 class="directory">/etc/udev/rules.d/</filename> directory. These are 126 numbered in a similar fashion to the CLFS-Bootscripts package. If 127 <command>udevd</command> can't find a rule for the device it is creating, 128 it will default permissions to <emphasis>660</emphasis> and ownership to 129 <emphasis>root:root</emphasis>.</para> 130 131 </sect3> 132 133 <sect3> 134 <title>Systemd and Eudev</title> 135 136 <para>In May 2012, Udev's source was merged with systemd, an alternate 137 <command>init</command> implementation. Some time later, several Gentoo 138 developers took the Udev code from systemd and created a fork called 139 Eudev.</para> 140 141 </sect3> 142 143 </sect2> 144 145 <sect2> 146 <title>Module Loading</title> 147 148 <para>Device drivers compiled as modules may have aliases built into them. 149 Aliases are visible in the output of the <command>modinfo</command> 150 program and are usually related to the bus-specific identifiers of devices 151 supported by a module. For example, the <emphasis>snd-fm801</emphasis> 152 driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801, 153 and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>. 154 For most devices, the bus driver exports the alias of the driver that 155 would handle the device via <systemitem 156 class="filesystem">sysfs</systemitem>. E.g., the 157 <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file 158 might contain the string 159 <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>. 160 The default rules provided by Udev will cause <command>udevd</command> 161 to call out to <command>/sbin/modprobe</command> with the contents of the 162 <envar>MODALIAS</envar> uevent environment variable (that should be the 163 same as the contents of the <filename>modalias</filename> file in sysfs), 164 thus loading all modules whose aliases match this string after wildcard 165 expansion.</para> 166 167 <para>In this example, this means that, in addition to 168 <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted) 169 <emphasis>forte</emphasis> driver will be loaded if it is 170 available. See below for ways in which the loading of unwanted drivers can 171 be prevented.</para> 172 173 <para>The kernel itself is also able to load modules for network 174 protocols, filesystems and NLS support on demand.</para> 175 176 </sect2> 177 178 <sect2> 179 <title>Handling Hotpluggable/Dynamic Devices</title> 180 181 <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3 182 player, the kernel recognizes that the device is now connected and 183 generates a uevent. This uevent is then handled by 184 <command>udevd</command> as described above.</para> 158 185 159 186 </sect2> … … 208 235 sound cards available to OSS applications), configure 209 236 <command>modprobe</command> to load the wrapper after Udev loads the 210 wrapped module. To do this, add an <quote>install</quote> line to a file211 in <filename>/etc/modprobe.d</filename>. For example:</para>237 wrapped module. To do this, add an <quote>install</quote> line in 238 <filename>/etc/modprobe.conf</filename>. For example:</para> 212 239 213 240 <screen role="nodump"><literal>install snd-pcm /sbin/modprobe -i snd-pcm ; \ 214 241 /sbin/modprobe snd-pcm-oss ; true</literal></screen> 215 242 243 <para>If the module in question is not a wrapper and is useful by itself, 244 configure the <command>S05modules</command> bootscript to load this 245 module on system boot. To do this, add the module name to the 246 <filename>/etc/sysconfig/modules</filename> file on a separate line. 247 This works for wrapper modules too, but is suboptimal in that case.</para> 248 216 249 </sect3> 217 250 … … 220 253 221 254 <para>Either don't build the module, or blacklist it in 222 <filename>/etc/modprobe. d</filename> file as done with the255 <filename>/etc/modprobe.conf</filename> file as done with the 223 256 <emphasis>forte</emphasis> module in the example below:</para> 224 257 … … 256 289 257 290 <sect3> 258 <title>Udev does not create a device</title>259 260 <para>Further text assumes that the driver is built statically into the261 kernel or already loaded as a module, and that you have already checked262 that Udev doesn't create a misnamed device.</para>263 264 <para>Udev has no information needed to create a device node if a kernel265 driver does not export its data to <systemitem266 class="filesystem">sysfs</systemitem>.267 This is most common with third party drivers from outside the kernel268 tree. Create a static device node in269 <filename>/lib/udev/devices</filename> with the appropriate major/minor270 numbers (see the file <filename>devices.txt</filename> inside the kernel271 documentation or the documentation provided by the third party driver272 vendor). The static device node will be copied to273 <filename class="directory">/dev</filename> by the274 <command>S10udev</command> bootscript.</para>275 276 </sect3>277 278 <sect3>279 291 <title>Device naming order changes randomly after rebooting</title> 280 292
Note:
See TracChangeset
for help on using the changeset viewer.