- Timestamp:
- 08/09/2004 02:44:30 AM (20 years ago)
- Branches:
- 6.0
- Children:
- 68450d5
- Parents:
- 6b85f8a
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter07/udev.xml
r6b85f8a r0cb7f8b 5 5 ]> 6 6 <sect1 id="ch-scripts-udev"> 7 <title>Device &Module handling on an LFS system</title>7 <title>Device and Module handling on an LFS system</title> 8 8 <?dbhtml filename="udev.html"?> 9 9 … … 17 17 order.</para> 18 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 22 nodes), regardless of whether the corresponding hardware devices 23 actually exist. This is typically 24 done via a <command>MAKEDEV</command> script (or similar), which 25 simply contains a number 26 of calls to the 'mknod' program with the relevant major and minor 27 device numbers for every possible device that might exist in the world. Using the udev method, only 28 those devices which are detected by the kernel get device nodes 29 created for them. As these device nodes will be created each time the 30 system boots, they will be stored on a <systemitem 31 class="filesystem">ramfs</systemitem> (a file system that 19 <para>Linux systems in general traditionally use a static device 20 creation method, whereby a great many device nodes are created under 21 <filename class="directory">/dev</filename> (sometimes literally 22 thousands of nodes), regardless of whether the corresponding hardware 23 devices actually exist. This is typically done via a 24 <command>MAKEDEV</command> script, which simply contains a number of 25 calls to the 'mknod' program with the relevant major and minor device 26 numbers for every possible device that might exist in the world. Using 27 the udev method, only those devices which are detected by the kernel 28 get device nodes created for them. As these device nodes will be 29 created each time the system boots, they will be stored on a 30 <systemitem class="filesystem">ramfs</systemitem> (a file system that 32 31 resides entirely in memory and does not take up any disk space). 33 32 Device nodes do not require much disk space, so the memory that is … … 41 40 kernel and was made generally available during the 2.4 series of 42 41 stable kernels. Although it was present in the kernel source itself, 43 this method of creating devices dynamically has never received 44 overwhelming support from the core kernel developers. The main 45 problems with the approach adopted by 46 <systemitem class="filesystem">devfs</systemitem> were seen to be that it 47 handled device detection, creation and naming all in the one place. 48 The latter issue, that of device node naming, was perhaps the most 49 critical. It is generally accepted that if you are to allow device 50 names to be configurable then the device naming policy should be up to 51 a system administrator, not imposed upon them by any particular 52 developer(s). <systemitem class="filesystem">devfs</systemitem> also suffers from race conditions that are 53 inherent in its design, and are cannot be fixed without a considerable 54 rewrite of the entire code. It has also been marked as deprecated due 55 to a lack of recent maintenance.</para> 56 57 <para>With the development of the unstable 2.5 kernel tree, later released 58 as the 2.6 series of stable kernels, came a new virtual filesystem 59 called <systemitem class="filesystem">sysfs</systemitem>. The job of 60 <systemitem class="filesystem">sysfs</systemitem> is to export a view of the system's 61 structure to userspace processes. With this userspace visible 62 representation, the possibility of seeing a userspace replacement for 63 <systemitem class="filesystem">devfs</systemitem> became much more realistic.</para> 64 </sect2> 42 this method of creating devices dynamically never received 43 overwhelming support from the core kernel developers. 44 45 <para>The main problem with the approach adopted by <systemitem 46 class="filesystem">devfs</systemitem> was the way that it handled 47 device detection, creation, and naming. The latter issue, that of 48 device node naming, was perhaps the most critical. It is generally 49 accepted that if you are to allow device names to be configurable then 50 the device naming policy should be up to a system administrator, not 51 imposed upon them by any particular developer(s). <systemitem 52 class="filesystem">devfs</systemitem> also suffers from race 53 conditions that are inherent in its design, and cannot be fixed 54 without a substantial revision to the kernel. It has also been marked 55 as deprecated due to a lack of recent maintenance.</para> 56 57 <para>With the development of the unstable 2.5 kernel tree, later 58 released as the 2.6 series of stable kernels, came a new virtual 59 filesystem called <systemitem class="filesystem">sysfs</systemitem>. 60 The job of <systemitem class="filesystem">sysfs</systemitem> is to 61 export a view of the system's structure to userspace processes. With 62 this userspace visible representation, the possibility of seeing a 63 userspace replacement for <systemitem 64 class="filesystem">devfs</systemitem> became much more 65 realistic.</para> </sect2> 65 66 66 67 <sect2> … … 71 72 class="filesystem">sysfs</systemitem> knows about the devices present 72 73 on a system, and what device numbers should be used. Drivers that 73 have been compiled into the kernel directly ,register their objects74 have been compiled into the kernel directly register their objects 74 75 with <systemitem class="filesystem">sysfs</systemitem> as they are 75 76 detected by the kernel. For drivers compiled as modules, this will … … 79 80 built-in drivers registered with <systemitem 80 81 class="filesystem">sysfs</systemitem> is available to userspace 81 processes and for <command>udev</command> to create device nodes from.</para>82 processes and to <command>udev</command> for device node creation.</para> 82 83 83 84 <para>The <command>S10udev</command> initscript takes care of creating 84 these device nodes when Linux is booted. Th e first thing this script85 does is registering <command>/sbin/udev</command> as a hotplug event 86 handler. Hotplug events should not be generated during this stage, 87 but it is registered just in case they do. The 88 <command>udevstart</command> program then walks through the 89 <systemitem class="filesystem">/sys</systemitem> filesystem and85 these device nodes when Linux is booted. This script starts with 86 registering <command>/sbin/udev</command> as a hotplug event handler. 87 Hotplug events (discussed below) should not be generated during this 88 stage, but <command>udev</command> is registered just in case they do 89 occur. The <command>udevstart</command> program then walks through 90 the <systemitem class="filesystem">/sys</systemitem> filesystem and 90 91 creates devices under <filename class="directory">/dev</filename> that 91 92 match the descriptions. For example, … … 97 98 from the <filename 98 99 class="directory">/etc/udev.d/permissions.d/</filename> directory. 99 These are numbered in a similar fashion to our bootscripts. If 100 <command>udev</command> can't find a permissions file for the device 101 it is creating, it will default to <emphasis>600</emphasis> and 100 These are numbered in a similar fashion to the LFS bootscripts. If 101 <command>udev</command> cannot find a permissions file for the device 102 it is creating, it will default permissions to 103 <emphasis>600</emphasis> and ownership to 102 104 <emphasis>root:root</emphasis>. The names of the nodes created under 103 105 the <filename class="directory">/dev</filename> directory are … … 112 114 <para>We mentioned earlier the concept of a <quote>hotplug event 113 115 handler</quote>. When a new device connection is detected by the 114 kernel, the kernel will generate a hotplug event ,and look at the file116 kernel, the kernel will generate a hotplug event and look at the file 115 117 <filename>/proc/sys/kernel/hotplug</filename> to find out the 116 userspace program to handle that device connection. The118 userspace program to handle that device's connection. The 117 119 <command>udev</command> initscript registered <command>udev</command> 118 120 as this handler. When these hotplug events are generated, the kernel … … 130 132 the appropriate kernel module to load. With <command>udev</command>, 131 133 this method will not work because the device node does not exist until 132 the module is loaded. To solve this, a bootscript was added, 133 <command>S05modules</command> to the lfs-bootscripts package along 134 with the <filename>/etc/sysconfig/modules</filename> file. By adding 135 module names to the <filename>modules</filename> file, these modules 136 will be loaded when the computer is starting up. This allows 137 <command>udev</command> to detect them and create device nodes 138 for.</para> 139 140 <para>One thing to note is that on slower machines, or for drivers that 141 create a lot of device nodes, the process of creating devices may take 142 a few seconds to complete. This means that some device nodes may not be 134 the module is loaded. To solve this, the 135 <command>S05modules</command> bootscript was added to the 136 lfs-bootscripts package along with the 137 <filename>/etc/sysconfig/modules</filename> file. By adding module 138 names to the <filename>modules</filename> file, these modules will be 139 loaded when the computer is starting up. This allows 140 <command>udev</command> to detect the devices and create the 141 appropriate device nodes.</para> 142 143 <para>Note that on slower machines, or for drivers that create a lot 144 of device nodes, the process of creating devices may take a few 145 seconds to complete. This means that some device nodes may not be 143 146 immediately accessible.</para> 144 147 </sect2> … … 148 151 149 152 <para>When you plug in a device, e.g. a USB MP3 player, the kernel 150 recogni ses that the device is now connected and generates a hotplug153 recognizes that the device is now connected and generates a hotplug 151 154 event. The driver will already have been loaded (either because it was 152 155 compiled into the kernel, or it was loaded via the … … 169 172 created. You can use the 170 173 <filename>/etc/sysconfig/createfiles</filename> configuration file to 171 manually create the devices. You may end up consultingthe172 <filename>devices.txt</filename> file inside your kernel 173 documentation, or the documentation for that driver to find the proper174 major/minornumbers.</para>174 manually create the devices. Consult the 175 <filename>devices.txt</filename> file inside your kernel documentation 176 or the documentation for that driver to find the proper major/minor 177 numbers.</para> 175 178 176 179 <para>2) A non-hardware device is required. This is most common with the 177 180 ALSA project's OSS compatibility module. These types of devices can 178 be handled in one of 2ways:</para>181 be handled in one of two ways:</para> 179 182 180 183 <itemizedlist> … … 186 189 <filename>/etc/modprobe.conf</filename>. Basically, this tells the 187 190 modprobe command <quote>when loading this module, also load this other 188 module, at the same time </quote>.For example:</para>191 module, at the same time.</quote> For example:</para> 189 192 190 193 <screen><userinput>install snd-pcm modprobe -i snd-pcm ; modprobe snd-pcm-oss ; true</userinput></screen>
Note:
See TracChangeset
for help on using the changeset viewer.