Correct capitalization, patch up grammar and idiom.

Regularized capital letters in <title> 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.

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 &ndash; due to a lack of maintenance &ndash; 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