Changeset ae20451 for chapter07/udev.xml
- Timestamp:
- 02/08/2006 08:17:00 PM (19 years ago)
- Children:
- 5e9d88c
- Parents:
- ad2c960
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter07/udev.xml
rad2c960 rae20451 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 hardrware 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> 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> 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>udev</command> for device 90 node creation.</para> 91 </sect3> 92 93 <sect3> 94 <title>Udev Bootscript</title> 95 96 <para>The <command>S10udev</command> initscript takes care of creating 97 device nodes when Linux is booted. The script starts by unsetting the 98 hotplug event handler from the default of <command>/sbin/hotplug</command> 99 This is done because, instead of the kernel calling out to an external 100 binary, <command>udev</command> will listen on a netlink socket for 101 hotplug events that the kernel raises. The bootscript copies any static 102 device nodes that exist in <filename 103 class="directory">/lib/udev/devices</filename> to <filename 104 class="directory">/dev</filename>. This is necessary because some devices 105 are needed before the dynamic device handling processes are available 106 during the early stages of booting a system. Creating static device nodes 107 in <filename class="directory">/lib/udev/devices</filename> also provides 108 an easy workaround for devices that are not supported by the dynamic 109 device handling infrastructure. The bootscript then starts the Udev 110 daemon, <command>udevd</command>, which will act on any hotplug events it 111 receives. Finally, the bootscript "coldplugs" any devices that 112 have already been registered with the kernel by forcing them to raise 113 hotplug events which <command>udevd</command> will then handle.</para> 114 </sect3> 115 116 <sect3> 117 <title>Device Node Creation</title> 118 119 <para>To obtain the right major and minor number for a device, Udev relies 120 on the information provided by <systemitem 121 class="filesystem">sysfs</systemitem> in <filename 122 class="directory">/sys</filename>. For example, 123 <filename>/sys/class/tty/vcs/dev</filename> contains the string 124 <quote>7:0</quote>. This string is used by <command>udevd</command> 125 to create a device node with major number <emphasis>7</emphasis> and minor 126 <emphasis>0</emphasis>. The names and permissions of the nodes created 127 under the <filename class="directory">/dev</filename> directory are 128 determined by rules specified in the files within the <filename 129 class="directory">/etc/udev/rules.d/</filename> directory. These are 130 numbered in a similar fashion to the LFS-Bootscripts package. If 131 <command>udevd</command> can't find a rule for the device it is creating, 132 it will default permissions to <emphasis>660</emphasis> and ownership to 133 <emphasis>root:root</emphasis>. Documentation on the syntax of the Udev 134 rules configuration files are available in 135 <filename>/usr/share/doc/udev-084/index.html</filename></para> 136 </sect3> 137 138 <sect3> 139 <title>Module Loading</title> 140 141 <para>If a device driver has been compiled as a module, the rules that 142 LFS installs will cause <command>udevd</command> to call out to 143 <command>/sbin/modprobe</command> with the name of the corresponding 144 module, thereby loading the driver.</para> 145 </sect3> 146 147 <sect3> 148 <title>Handling Hotpluggable/Dynamic Devices</title> 149 150 <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3 151 player, the kernel recognizes that the device is now connected and 152 generates a hotplug event. This hotplug event is then handled by 153 <command>udevd</command> as described above.</para> 154 </sect3> 155 156 <!-- FIXME: These are questions Matt thought of while rewriting this page 157 to reflect the hotplug-less setup but didn't have time to investigate 158 straight away. 159 <sect3> 160 <title>Questions?</title> 161 162 <para>7.4.2.3: Are default ownership/permissions still 0660 root:root? I 163 thought they'd changed, but can't be sure. Running without a config file 164 will prove this pretty quickly.</para> 165 166 <para>7.4.2.4: How does <command>udevd</command> know which driver to 167 load, i.e. the correct module name? Is it in the hotplug event? I don't 168 think it can be in /sys as that won't be populated yet (it's the driver 169 itself that populates /sys, after all).</para> 170 171 <para>Is the S05modules script still required? If so, what are the use 172 cases for it?</para> 173 174 </sect3> --> 158 175 159 176 </sect2> … … 170 187 <para>This is most common with third party drivers from outside the kernel 171 188 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> 189 drivers. Create a static device node in 190 <filename>/lib/udev/devices</filename> with the appropriate major/minor 191 numbers (see the file <filename>devices.txt</filename> inside the kernel 192 documentation or the documentation provided by the third party driver 193 vendor). The static device node will be copied to 194 <filename class="directory">/dev</filename> by the 195 <command>S10udev</command> bootscript.</para> 177 196 178 197 <para>2) A non-hardware device is required. This is most common with
Note:
See TracChangeset
for help on using the changeset viewer.