diff options
| -rw-r--r-- | chapter09/udev.xml | 76 |
1 files changed, 38 insertions, 38 deletions
diff --git a/chapter09/udev.xml b/chapter09/udev.xml index 396f2b389..4bcb52dfe 100644 --- a/chapter09/udev.xml +++ b/chapter09/udev.xml @@ -16,23 +16,23 @@ </indexterm> <para>In <xref linkend="chapter-building-system"/>, we installed the udev - package when <phrase revision="sysv">eudev</phrase> + daemon when <phrase revision="sysv">eudev</phrase> <phrase revision="systemd">systemd</phrase> was built. Before we go into the - details regarding how this works, a brief history of previous methods of + details regarding how udev works, a brief history of previous methods of handling devices is in order.</para> <para>Linux systems in general traditionally used a static device creation method, whereby a great many device nodes were created under <filename class="directory">/dev</filename> (sometimes literally thousands of nodes), regardless of whether the corresponding hardware devices actually existed. This - was typically done via a <command>MAKEDEV</command> script, which contains a + was typically done via a <command>MAKEDEV</command> script, which contained a number of calls to the <command>mknod</command> program with the relevant major and minor device numbers for every possible device that might exist in the world.</para> - <para>Using the udev method, only those devices which are detected by the - kernel get device nodes created for them. Because these device nodes will be - created each time the system boots, they will be stored on a <systemitem + <para>Using the udev method, device nodes are only created for those devices + which are detected by the kernel. These device nodes are + created each time the system boots; they are stored in a <systemitem class="filesystem">devtmpfs</systemitem> file system (a virtual file system that resides entirely in system memory). Device nodes do not require much space, so the memory that is used is negligible.</para> @@ -51,23 +51,23 @@ class="filesystem">devfs</systemitem> was the way it handled device detection, creation, and naming. The latter issue, that of device node naming, was perhaps the most critical. It is generally accepted that if - device names are allowed to be configurable, then the device naming policy - should be up to a system administrator, not imposed on them by any - particular developer(s). The <systemitem + device names are configurable, the device naming policy + should be chosen by system administrators, and not imposed on them by the + developer(s). The <systemitem class="filesystem">devfs</systemitem> file system also suffered from race - conditions that were inherent in its design and could not be fixed without a - substantial revision to the kernel. It was marked as deprecated for a long - period – due to a lack of maintenance – and was finally removed + conditions that were inherent in its design; these could not be fixed without a + substantial revision of the kernel. <systemitem class="filesystem">devfs</systemitem> + was marked as deprecated for a long + time, and was finally removed from the kernel in June, 2006.</para> <para>With the development of the unstable 2.5 kernel tree, later released as the 2.6 series of stable kernels, a new virtual filesystem called <systemitem class="filesystem">sysfs</systemitem> came to be. The job of - <systemitem class="filesystem">sysfs</systemitem> is to export a view of + <systemitem class="filesystem">sysfs</systemitem> is to provide information about the system's hardware configuration to userspace processes. With this - userspace-visible representation, the possibility of developing a userspace - replacement for <systemitem class="filesystem">devfs</systemitem> became - much more realistic.</para> + userspace-visible representation, it became possible to develop a userspace + replacement for <systemitem class="filesystem">devfs</systemitem>.</para> </sect2> @@ -81,12 +81,12 @@ was mentioned briefly above. One may wonder how <systemitem class="filesystem">sysfs</systemitem> knows about the devices present on a system and what device numbers should be used for them. Drivers that - have been compiled into the kernel directly register their objects with a + have been compiled into the kernel register their objects in <systemitem class="filesystem">sysfs</systemitem> (devtmpfs internally) - as they are detected by the kernel. For drivers compiled as modules, this - registration will happen when the module is loaded. Once the <systemitem + as they are detected by the kernel. For drivers compiled as modules, + registration happens when the module is loaded. Once the <systemitem class="filesystem">sysfs</systemitem> filesystem is mounted (on /sys), - data which the drivers register with <systemitem + data which the drivers have registered with <systemitem class="filesystem">sysfs</systemitem> are available to userspace processes and to udevd for processing (including modifications to device nodes).</para> @@ -96,13 +96,13 @@ <sect3 id='ch-config-udev-device-node-creation'> <title>Device Node Creation</title> - <para>Device files are created by the kernel by the <systemitem - class="filesystem">devtmpfs</systemitem> filesystem. Any driver that - wishes to register a device node will go through the <systemitem + <para>Device files are created by the kernel in the <systemitem + class="filesystem">devtmpfs</systemitem> file system. Any driver that + wishes to register a device node will use the <systemitem class="filesystem">devtmpfs</systemitem> (via the driver core) to do it. When a <systemitem class="filesystem">devtmpfs</systemitem> instance is mounted on <filename class="directory">/dev</filename>, the device node - will initially be created with a fixed name, permissions, and + will initially be exposed to userspace with a fixed name, permissions, and owner.</para> <para>A short time later, the kernel will send a uevent to <command> @@ -172,7 +172,7 @@ creating device nodes.</para> <sect3> - <title>A kernel module is not loaded automatically</title> + <title>A Kernel Module Is Not Loaded Automatically</title> <para>Udev will only load a module if it has a bus-specific alias and the bus driver properly exports the necessary aliases to <systemitem @@ -206,8 +206,8 @@ </sect3> <sect3> - <title>A kernel module is not loaded automatically, and udev is not - intended to load it</title> + <title>A Kernel Module Is Not Loaded Automatically, and Udev Is Not + Intended to Load It</title> <para>If the <quote>wrapper</quote> module only enhances the functionality provided by some other module (e.g., @@ -236,7 +236,7 @@ </sect3> <sect3> - <title>Udev loads some unwanted module</title> + <title>Udev Loads Some Unwanted Module</title> <para>Either don't build the module, or blacklist it in a <filename>/etc/modprobe.d/blacklist.conf</filename> file as done with the @@ -250,7 +250,7 @@ </sect3> <sect3> - <title>Udev creates a device incorrectly, or makes a wrong symlink</title> + <title>Udev Creates a Device Incorrectly, or Makes the Wrong Symlink</title> <para>This usually happens if a rule unexpectedly matches a device. For example, a poorly-written rule can match both a SCSI disk (as desired) @@ -261,7 +261,7 @@ </sect3> <sect3> - <title>Udev rule works unreliably</title> + <title>Udev Rule Works Unreliably</title> <para>This may be another manifestation of the previous problem. If not, and your rule uses <systemitem class="filesystem">sysfs</systemitem> @@ -275,15 +275,15 @@ </sect3> <sect3> - <title>Udev does not create a device</title> + <title>Udev Does Not Create a Device</title> - <para>Further text assumes that the driver is built statically into the - kernel or already loaded as a module, and that you have already checked - that udev doesn't create a misnamed device.</para> + <para>First, be certain that the driver is built into the + kernel or already loaded as a module, and that + udev isn't creating a misnamed device.</para> - <para>Udev has no information needed to create a device node if a kernel - driver does not export its data to - <systemitem class="filesystem">sysfs</systemitem>. This is most common + <para>If a kernel driver does not export its data to + <systemitem class="filesystem">sysfs</systemitem>, udev lacks the + information needed to create a device node. This is most likely to happen with third party drivers from outside the kernel tree. Create a static device node in <filename>/usr/lib/udev/devices</filename> with the appropriate major/minor numbers (see the file @@ -295,7 +295,7 @@ </sect3> <sect3> - <title>Device naming order changes randomly after rebooting</title> + <title>Device Naming Order Changes Randomly After Rebooting</title> <para>This is due to the fact that udev, by design, handles uevents and loads modules in parallel, and thus in an unpredictable order. This will |