From 6ef50538b2bf9d57c9856ea002a1efa12204e7a4 Mon Sep 17 00:00:00 2001 From: David Bryant Date: Wed, 21 Dec 2022 16:13:16 -0600 Subject: Correct capitalization, patch up grammar and idiom. Regularized capital letters in lines. Changed a dependent clause and made it independent. Smoothed out some bumpy verbiage in the "History" section. Removed superfluous verbiage. Clarified some trounbleshooting advice. --- chapter09/udev.xml | 76 +++++++++++++++++++++++++++--------------------------- 1 file changed, 38 insertions(+), 38 deletions(-) (limited to 'chapter09/udev.xml') 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 - Device files are created by the kernel by the devtmpfs filesystem. Any driver that - wishes to register a device node will go through the Device files are created by the kernel in the devtmpfs file system. Any driver that + wishes to register a device node will use the devtmpfs (via the driver core) to do it. When a devtmpfs instance is mounted on /dev, 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. A short time later, the kernel will send a uevent to @@ -172,7 +172,7 @@ creating device nodes. - A kernel module is not loaded automatically + A Kernel Module Is Not Loaded Automatically Udev will only load a module if it has a bus-specific alias and the bus driver properly exports the necessary aliases to - A kernel module is not loaded automatically, and udev is not - intended to load it + A Kernel Module Is Not Loaded Automatically, and Udev Is Not + Intended to Load It If the wrapper module only enhances the functionality provided by some other module (e.g., @@ -236,7 +236,7 @@ - Udev loads some unwanted module + Udev Loads Some Unwanted Module Either don't build the module, or blacklist it in a /etc/modprobe.d/blacklist.conf file as done with the @@ -250,7 +250,7 @@ - Udev creates a device incorrectly, or makes a wrong symlink + Udev Creates a Device Incorrectly, or Makes the Wrong Symlink 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 @@ - Udev rule works unreliably + Udev Rule Works Unreliably This may be another manifestation of the previous problem. If not, and your rule uses sysfs @@ -275,15 +275,15 @@ - Udev does not create a device + Udev Does Not Create a Device - 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. + 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. - Udev has no information needed to create a device node if a kernel - driver does not export its data to - sysfs. This is most common + If a kernel driver does not export its data to + sysfs, 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 /usr/lib/udev/devices with the appropriate major/minor numbers (see the file @@ -295,7 +295,7 @@ - Device naming order changes randomly after rebooting + Device Naming Order Changes Randomly After Rebooting 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 -- cgit v1.2.3-54-g00ecf