Clean up / clarify disccussion; correct capitalization of titles.

Clarify discussion of "eth0" vs "enp5s0". Remove superfluous verbiage.
Improve punctuation. Patch grammatical errors (subject / verb).
Improve English idiom in a few places.

1 files changed, 37 insertions, 37 deletions

diff --git a/chapter09/symlinks.xml b/chapter09/symlinks.xml
index 24ebf537d..86528ba69 100644
--- a/chapter09/symlinks.xml
+++ b/chapter09/symlinks.xml
@@ -17,27 +17,28 @@
     <para>Udev, by default, names network devices according to Firmware/BIOS
     data or physical characteristics like the bus, slot, or MAC address.  The
     purpose of this naming convention is to ensure that network devices are
-    named consistently and not based on the time the network card was
-    discovered.  For example, on a computer having two network cards made by
-    Intel and Realtek, the network card manufactured by Intel may become eth0
-    and the Realtek card becomes eth1. In some cases, after a reboot the cards
-    could get renumbered the other way around.</para>
-
-    <para>In the new naming scheme, typical network device names would then
-    be something like enp5s0 or wlp3s0.  If this naming convention is not
-    desired, the traditional naming scheme or a custom scheme can be
+    named consistently, not based on when the network card was
+    discovered.  In older versions of Linux&mdash;on a computer with two 
+    network cards made by Intel and Realtek, for instance&mdash;the
+    network card manufactured by Intel might have become eth0
+    while the Realtek card became eth1. After a reboot, the cards
+    would sometimes get renumbered the other way around.</para>
+
+    <para>In the new naming scheme, typical network device names are
+    something like enp5s0 or wlp3s0.  If this naming convention is not
+    desired, the traditional naming scheme, or a custom scheme, can be
     implemented.</para>
 
     <sect3>
       <title>Disabling Persistent Naming on the Kernel Command Line</title>
 
-      <para>The traditional naming scheme using eth0, eth1, etc can be
+      <para>The traditional naming scheme using eth0, eth1, etc. can be
       restored by adding <userinput>net.ifnames=0</userinput> on the
-      kernel command line.  This is most appropriate for those systems
-      that have only one ethernet device of the same type.  Laptops
-      often have multiple ethernet connections that are named eth0 and
-      wlan0 and are also candidates for this method.  The command line
-      is passed in the GRUB configuration file.
+      kernel command line.  This is most appropriate for systems
+      that have just one ethernet device of a particular type.  Laptops
+      often have two ethernet connections named eth0 and
+      wlan0; such laptops can also use this method.  The command line
+      is in the GRUB configuration file.
       See <xref linkend="grub-cfg"/>.</para>
     </sect3>
 
@@ -56,23 +57,22 @@
 
 <screen role="nodump"><userinput>cat /etc/udev/rules.d/70-persistent-net.rules</userinput></screen>
 
-      <note><para>In some cases such as when MAC addresses have been assigned to
-      a network card manually or in a virtual environment such as Qemu or Xen,
-      the network rules file may not have been generated because addresses
+      <note><para>In some cases, such as when MAC addresses have been assigned to
+      a network card manually, or in a virtual environment such as Qemu or Xen,
+      the network rules file may not be generated because addresses
       are not consistently assigned.  In these cases, this method cannot
       be used.</para></note>
 
-      <para>The file begins with a comment block followed by two lines for each
+      <para>The file begins with a comment block, followed by two lines for each
       NIC. The first line for each NIC is a commented description showing its
       hardware IDs (e.g. its PCI vendor and device IDs, if it's a PCI card),
-      along with its driver in parentheses, if the driver can be found. Neither
+      along with its driver (in parentheses, if the driver can be found). Neither
       the hardware ID nor the driver is used to determine which name to give an
       interface; this information is only for reference. The second line is the
       udev rule that matches this NIC and actually assigns it a name.</para>
 
-      <para>All udev rules are made up of several keys, separated by commas and
-      optional whitespace. This rule's keys and an explanation of each of them
-      are as follows:</para>
+      <para>All udev rules are made up of several keywords, separated by commas and
+      optional whitespace. Here are the keywords, and an explanation of each one:</para>
 
       <itemizedlist>
         <listitem>
@@ -88,10 +88,10 @@
           <para><literal>DRIVERS=="?*"</literal> - This exists so that udev will
           ignore VLAN or bridge sub-interfaces (because these sub-interfaces do
           not have drivers). These sub-interfaces are skipped because the name
-          that would be assigned would collide with their parent devices.</para>
+          that would be assigned would collide with the parent devices.</para>
         </listitem>
         <listitem>
-          <para><literal>ATTR{address}</literal> - The value of this key is the
+          <para><literal>ATTR{address}</literal> - The value of this keyword is the
           NIC's MAC address.</para>
         </listitem>
         <listitem>
@@ -102,7 +102,7 @@
           skipped: there would be a name collision otherwise.</para>
         </listitem>
         <listitem>
-          <para><literal>NAME</literal> - The value of this key is the name that
+          <para><literal>NAME</literal> - The value of this keyword is the name that
           udev will assign to this interface.</para>
         </listitem>
       </itemizedlist>
@@ -110,7 +110,7 @@
       <para>The value of <literal>NAME</literal> is the important part. Make sure
       you know which name has been assigned to each of your network cards before
       proceeding, and be sure to use that <literal>NAME</literal> value when
-      creating your configuration files below.</para>
+      creating your network configuration files.</para>
 
     </sect3>
 
@@ -118,10 +118,10 @@
 
   <sect2 revision="sysv">
 
-    <title>CD-ROM symlinks</title>
+    <title>CD-ROM Symlinks</title>
 
     <para>Some software that you may want to install later (e.g., various
-    media players) expect the <filename class="symlink">/dev/cdrom</filename>
+    media players) expects the <filename class="symlink">/dev/cdrom</filename>
     and <filename class="symlink">/dev/dvd</filename> symlinks to exist, and
     to point to a CD-ROM or DVD-ROM device. Also, it may be convenient to put
     references to those symlinks into <filename>/etc/fstab</filename>. Udev
@@ -139,15 +139,15 @@
     <command>ata_id</command> or <command>scsi_id</command> programs, depending
     on which type of device you have.</para>
 
-    <para>There are advantages to each approach; the correct approach to use
-    will depend on what kinds of device changes may happen. If you expect the
+    <para>There are advantages to each approach; the correct approach
+    depends on what kinds of device changes may happen. If you expect the
     physical path to the device (that is, the ports and/or slots that it plugs
     into) to change, for example because you plan on moving the drive to a
     different IDE port or a different USB connector, then you should use the
     <quote>by-id</quote> mode. On the other hand, if you expect the device's
-    identification to change, for example because it may die, and you would
-    replace it with a different device with the same capabilities and which
-    is plugged into the same connectors, then you should use the
+    identification to change, for example because it may die, and you intend
+    to replace it with a different device that 
+    plugs into the same connectors, then you should use the
     <quote>by-path</quote> mode.</para>
 
     <para>If either type of change is possible with your drive, then choose a
@@ -198,13 +198,13 @@
     this is only an issue if you need the symlinks on both systems to point to
     the same device. If you need that, then inspect (and possibly edit) the
     generated <filename>/etc/udev/rules.d/70-persistent-cd.rules</filename>
-    file after booting, to make sure the assigned symlinks match what you need.</para>
+    file after booting, to make sure the assigned symlinks match your needs.</para>
 
   </sect2>
 
   <sect2>
 
-    <title>Dealing with duplicate devices</title>
+    <title>Dealing with Duplicate Devices</title>
 
     <para>As explained in <xref linkend="ch-config-udev"/>, the order in
     which devices with the same function appear in
@@ -214,7 +214,7 @@
     <filename>/dev/video1</filename> refers to the tuner, and sometimes
     after a reboot the order changes.
     For all classes of hardware except sound cards and network cards, this is
-    fixable by creating udev rules for custom persistent symlinks.
+    fixable by creating udev rules to create persistent symlinks.
     The case of network cards is covered separately in
     <xref linkend="ch-config-network"/>, and sound card configuration can
     be found in <ulink url="&blfs-book;postlfs/devices.html">BLFS</ulink>.</para>