- Timestamp:
- 05/21/14 16:05:07 (10 years ago)
- Branches:
- clfs-3.0.0-sysvinit, sysvinit
- Children:
- a720e96
- Parents:
- 7b8e852
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
BOOK/system-config/common/eudev.xml
r7b8e852 rf6721f7 21 21 order.</para> 22 22 23 <para>Linux systems in general traditionally use a static device creation24 method, whereby a great many device nodes are created under <filename25 class="directory">/dev</filename> (sometimes literally thousands of nodes),26 regardless of whether the corresponding hardware devices actually exist. This27 is typically done via a <command>MAKEDEV</command> script, which contains a28 number of calls to the <command>mknod</command> program with the relevant29 major and minor device numbers for every possible device that might exist in30 the world.</para>31 32 <para>Using the Eudev method, only those devices which are detected by the33 kernel get device nodes created for them. Because these device nodes will be34 created each time the system boots, they will be stored on a <systemitem35 class="filesystem">tmpfs</systemitem> file system (a virtual file system that36 resides entirely in system memory). Device nodes do not require much space, so37 the memory that is used is negligible.</para>38 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>Eudev 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>Eudev Bootscript</title> 96 97 <para>The <command>S10udev</command> initscript takes care of creating 98 device nodes when Linux is booted. The script unsets the uevent handler 99 from the default of <command>/sbin/hotplug</command>. This is done 100 because the kernel no longer needs to call out to an external binary. 101 Instead <command>udevd</command> will listen on a netlink socket for 102 uevents that the kernel raises. Next, 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 <filename 109 class="directory">/lib/udev/devices</filename> also provides an easy 110 workaround for devices that are not supported by the dynamic device 111 handling infrastructure. The bootscript then starts the Eudev daemon, 112 <command>udevd</command>, which will act on any uevents it receives. 113 Finally, the bootscript forces the kernel to replay uevents for any 114 devices that have already been registered and then waits for 115 <command>udevd</command> to handle them.</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, Eudev relies 123 on the information provided by <systemitem 124 class="filesystem">sysfs</systemitem> in <filename 125 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, 126 97 <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 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 131 124 determined by rules specified in the files within the <filename 132 125 class="directory">/etc/udev/rules.d/</filename> directory. These are … … 134 127 <command>udevd</command> can't find a rule for the device it is creating, 135 128 it will default permissions to <emphasis>660</emphasis> and ownership to 136 <emphasis>root:root</emphasis>. Documentation on the syntax of the Eudev 137 rules configuration files is available in 138 <filename>/usr/share/doc/udev/writing_udev_rules/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 default rules provided by Eudev will cause <command>udevd</command> 158 to call 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 uevent. This uevent is then handled by 181 <command>udevd</command> as described above.</para> 182 183 </sect3> 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 Eudev 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> 184 185 185 186 </sect2> … … 288 289 289 290 <sect3> 290 <title>Eudev does not create a device</title>291 292 <para>Further text assumes that the driver is built statically into the293 kernel or already loaded as a module, and that you have already checked294 that Eudev doesn't create a misnamed device.</para>295 296 <para>Eudev has no information needed to create a device node if a kernel297 driver does not export its data to <systemitem298 class="filesystem">sysfs</systemitem>.299 This is most common with third party drivers from outside the kernel300 tree. Create a static device node in301 <filename>/lib/udev/devices</filename> with the appropriate major/minor302 numbers (see the file <filename>devices.txt</filename> inside the kernel303 documentation or the documentation provided by the third party driver304 vendor). The static device node will be copied to305 <filename class="directory">/dev</filename> by the306 <command>S10udev</command> bootscript.</para>307 308 </sect3>309 310 <sect3>311 291 <title>Device naming order changes randomly after rebooting</title> 312 292
Note:
See TracChangeset
for help on using the changeset viewer.