Rewrite and reorganize Chapter 7.

Update systemd customization.


git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@10542 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

1 files changed, 17 insertions, 79 deletions

diff --git a/chapter07/udev.xml b/chapter07/udev.xml
index 7e11388d8..f8a73d8e9 100644
--- a/chapter07/udev.xml
+++ b/chapter07/udev.xml
@@ -8,7 +8,7 @@
 <sect1 id="ch-scripts-udev">
   <?dbhtml filename="udev.html"?>
 
-  <title>Device and Module Handling on an LFS System</title>
+  <title>Overview of Device and Module Handling</title>
 
   <indexterm zone="ch-scripts-udev">
     <primary sortas="a-Udev">Udev</primary>
@@ -16,15 +16,15 @@
   </indexterm>
 
   <para>In <xref linkend="chapter-building-system"/>, we installed the Udev
-  package. Before we go into the details regarding how this works,
-  a brief history of previous methods of handling devices is in
+  package as a part of systemd. Before we go into the details regarding how
+  this works, a brief history of previous methods of handling devices is in
   order.</para>
 
-  <para>Linux systems in general traditionally use a static device creation
-  method, whereby a great many device nodes are created under <filename
+  <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 exist. This
-  is typically done via a <command>MAKEDEV</command> script, which contains a
+  regardless of whether the corresponding hardware devices actually existed. This
+  was typically done via a <command>MAKEDEV</command> script, which contains 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>
@@ -53,8 +53,8 @@
     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
-    class="filesystem">devfs</systemitem> file system also suffers from race
-    conditions that are inherent in its design and cannot be fixed without a
+    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
     from the kernel in June, 2006.</para>
@@ -64,7 +64,7 @@
     <systemitem class="filesystem">sysfs</systemitem> came to be. The job of
     <systemitem class="filesystem">sysfs</systemitem> is to export a view of
     the system's hardware configuration to userspace processes. With this
-    userspace-visible representation, the possibility of seeing a userspace
+    userspace-visible representation, the possibility of developing a userspace
     replacement for <systemitem class="filesystem">devfs</systemitem> became
     much more realistic.</para>
 
@@ -97,7 +97,7 @@
 
       <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 <systemitem
+      wishes to register a device node will go through 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
@@ -113,53 +113,12 @@
       change its permissions, owner, or group, or modify the internal
       <command>udevd</command> database entry (name) for that object.</para>
 
-      <para>The rules in these three directories are numbered in a similar
-      fashion to the LFS-Bootscripts package and all three directories are
-      merged together. If <command>udevd</command> can't find a rule for the
-      device it is creating, it will leave the permissions and ownership at
-      whatever <systemitem class="filesystem">devtmpfs</systemitem> used
-      initially.</para> </sect3>
-
-    <sect3>
-      <title>Udev Bootscripts</title>
-
-      <para>The first LFS bootscript,
-      <filename>/etc/init.d/mountvirtfs</filename> will copy any devices
-      located in <filename class="directory">/lib/udev/devices</filename> to
-      <filename class="directory">/dev</filename>. This is necessary because
-      some devices, directories, and symlinks are needed before the dynamic
-      device handling processes are available during the early stages of
-      booting a system, or are required by <command>udevd</command> itself.
-      Creating static device nodes in <filename
-      class="directory">/lib/udev/devices</filename> also provides an easy
-      workaround for devices that are not supported by the dynamic device
-      handling infrastructure.</para>
-
-      <para>The <filename>/etc/rc.d/init.d/udev</filename> initscript starts
-      <command>udevd</command>, triggers any "coldplug" devices that have
-      already been created by the kernel and waits for any rules to complete.
-      The script also unsets the uevent handler from the default of
-      <filename>/sbin/hotplug </filename>.  This is done because the kernel no
-      longer needs to call out to an external binary.  Instead
-      <command>udevd</command> will listen on a netlink socket for uevents that
-      the kernel raises.</para>
-
-      <para>The <command>/etc/rc.d/init.d/udev_retry</command> initscript takes
-      care of re-triggering events for subsystems whose rules may rely on
-      filesystems that are not mounted until the <command>mountfs</command>
-      script is run (in particular, <filename class="directory">/usr</filename>
-      and <filename class="directory">/var</filename> may cause this).  This
-      script runs after the <command>mountfs</command> script, so those rules
-      (if re-triggered) should succeed the second time around.  It is
-      configured from the <filename>/etc/sysconfig/udev_retry</filename> file;
-      any words in this file other than comments are considered subsystem names
-      to trigger at retry time.  To find the subsystem of a device, use
-      <command>udevadm info --attribute-walk &lt;device&gt;</command> where
-      &lt;device&gt; is an absolute path in /dev or /sys such as /dev/sr0 or
-      /sys/class/rtc.</para>
-
-    </sect3>
-
+      <para>The rules in these three directories are numbered and all three
+      directories are merged together. If <command>udevd</command> can't find a
+      rule for the device it is creating, it will leave the permissions and
+      ownership at whatever <systemitem
+      class="filesystem">devtmpfs</systemitem> used initially.</para> </sect3>
+      
     <sect3>
       <title>Module Loading</title>
 
@@ -314,27 +273,6 @@
     </sect3>
 
     <sect3>
-      <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>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 with third party drivers from outside the kernel
-      tree. Create a static device node in
-      <filename>/lib/udev/devices</filename> with the appropriate major/minor
-      numbers (see the file <filename>devices.txt</filename> inside the kernel
-      documentation or the documentation provided by the third party driver
-      vendor). The static device node will be copied to
-      <filename class="directory">/dev</filename> by the
-      <command>udev</command> bootscript.</para>
-
-    </sect3>
-
-    <sect3>
       <title>Device naming order changes randomly after rebooting</title>
 
       <para>This is due to the fact that Udev, by design, handles uevents and