Automatic merge of trunk into multilib

chapter09/bootscripts.xml

@@ -74,7 +74,7 @@
         <term><command>checkfs</command></term>
         <listitem>
           <para>Checks the integrity of the file systems before they are mounted
-          (with the exception of journal and network based file systems)</para>
+          (with the exception of journaling and network-based file systems)</para>
           <indexterm zone="ch-config-bootscripts checkfs-bootscripts">
             <primary sortas="d-checkfs">checkfs</primary>
           </indexterm>
@@ -173,8 +173,8 @@
       <varlistentry id="mountfs-bootscripts">
         <term><command>mountfs</command></term>
         <listitem>
-          <para>Mounts all file systems, except ones that are marked
+          <para>Mounts all file systems, except those that are marked
-          <emphasis>noauto</emphasis> or are network based</para>
+          <emphasis>noauto</emphasis>, or are network based</para>
           <indexterm zone="ch-config-bootscripts mountfs-bootscripts">
             <primary sortas="d-mountfs">mountfs</primary>
           </indexterm>
@@ -208,7 +208,7 @@
         <listitem>
           <para>The master run-level control script; it is responsible for
           running all the other bootscripts one-by-one, in a sequence determined
-          by the name of the symbolic links being processed</para>
+          by the names of the symbolic links to those other bootscripts</para>
           <indexterm zone="ch-config-bootscripts rc-bootscripts">
             <primary sortas="d-rc">rc</primary>
           </indexterm>
@@ -239,8 +239,8 @@
       <varlistentry id="setclock-bootscripts">
         <term><command>setclock</command></term>
         <listitem>
-          <para>Resets the kernel clock to local time in case the hardware clock
+          <para>Resets the system clock to local time if the hardware clock
-          is not set to UTC time</para>
+          is not set to UTC</para>
           <indexterm zone="ch-config-bootscripts setclock-bootscripts">
             <primary sortas="d-setclock">setclock</primary>
           </indexterm>
@@ -305,7 +305,7 @@
         <term><command>udev</command></term>
         <listitem>
           <para>Prepares the <filename class="directory">/dev</filename>
-          directory and starts Udev</para>
+          directory and starts the udev daemon</para>
           <indexterm zone="ch-config-bootscripts udev-bootscripts">
             <primary sortas="d-udev">udev</primary>
           </indexterm>

chapter09/introduction.xml

@@ -11,19 +11,19 @@
   <title>Introduction</title>
 
     <para>Booting a Linux system involves several tasks.  The process must
-    mount both virtual and real file systems, initialize devices, activate swap,
+    mount both virtual and real file systems, initialize devices, 
-    check file systems for integrity, mount any swap partitions or files, set
+    check file systems for integrity, mount and activate any swap partitions or files, set
     the system clock, bring up networking, start any daemons required by the
-    system, and accomplish any other custom tasks needed by the user.  This
+    system, and accomplish any other custom tasks specified by the user.  This
     process must be organized to ensure the tasks are performed in the correct
-    order but, at the same time, be executed as fast as possible.</para>
+    order and executed as quickly as possible.</para>
 
   <sect2 id='sysv-desc'>
     <title>System V</title>
 
     <para>System V is the classic boot process that has been used in Unix and
     Unix-like systems such as Linux since about 1983.  It consists of a small
-    program, <command>init</command>, that sets up basic programs such as
+    program, <command>init</command>, that sets up basic processes such as
     <command>login</command> (via getty) and runs a script.  This script,
     usually named <command>rc</command>,  controls the execution of a set of
     additional scripts that perform the tasks required to initialize the
@@ -31,7 +31,7 @@
 
     <para>The <command>init</command> program is controlled by the
     <filename>/etc/inittab</filename> file and is organized into run levels that
-    can be run by the user. In LFS, they are used as follows:</para>
+    can be chosen by the user. In LFS, they are used as follows:</para>
 
 <literallayout>0 &mdash; halt
 1 &mdash; Single user mode
@@ -70,13 +70,13 @@
 
       <listitem>
           <para>Serial processing of boot tasks. This is related to the previous
-          point.  A delay in any process such as a file system check, will
+          point.  A delay in any process, such as a file system check, will
           delay the entire boot process.</para>
       </listitem>
 
       <listitem>
           <para>Does not directly support advanced features like
-          control groups (cgroups), and per-user fair share scheduling.</para>
+          control groups (cgroups) and per-user fair share scheduling.</para>
       </listitem>
 
       <listitem>

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
+  <para>Using the udev method, device nodes are only created for those devices
-  kernel get device nodes created for them. Because these device nodes will be
+  which are detected by the kernel. These device nodes are
-  created each time the system boots, they will be stored on a <systemitem
+  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
+    device names are configurable, the device naming policy
-    should be up to a system administrator, not imposed on them by any
+    should be chosen by system administrators, and not imposed on them by the
-    particular developer(s). The <systemitem
+    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
+    conditions that were inherent in its design; these could not be fixed without a
-    substantial revision to the kernel. It was marked as deprecated for a long
+    substantial revision of the kernel. <systemitem class="filesystem">devfs</systemitem>
-    period &ndash; due to a lack of maintenance &ndash; and was finally removed
+    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
+    userspace-visible representation, it became possible to develop a userspace
-    replacement for <systemitem class="filesystem">devfs</systemitem> became
+    replacement for <systemitem class="filesystem">devfs</systemitem>.</para>
-    much more realistic.</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
+      as they are detected by the kernel. For drivers compiled as modules,
-      registration will happen when the module is loaded. Once the <systemitem
+      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
+      <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 go through the <systemitem
+      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
+      <title>A Kernel Module Is Not Loaded Automatically, and Udev Is Not
-      intended to load it</title>
+      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
+      <para>First, be certain that the driver is built into the
-      kernel or already loaded as a module, and that you have already checked
+      kernel or already loaded as a module, and that
-      that udev doesn't create a misnamed device.</para>
+      udev isn't creating a misnamed device.</para>
 
-      <para>Udev has no information needed to create a device node if a kernel
+      <para>If a kernel driver does not export its data to
-      driver does not export its data to
+      <systemitem class="filesystem">sysfs</systemitem>, udev lacks the 
-      <systemitem class="filesystem">sysfs</systemitem>. This is most common
+      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