Index: BOOK/introduction/common/changelog.xml
===================================================================
--- BOOK/introduction/common/changelog.xml	(revision fab5058225038164452c9cac8081ec5b64470cda)
+++ BOOK/introduction/common/changelog.xml	(revision d46b6ed6d06381364935f9e0c62a35fe2d38108e)
@@ -38,4 +38,13 @@
 
     <listitem>
+      <para>21 May 2014</para>
+      <itemizedlist>
+        <listitem>
+          <para>[Chris] - Rewrote Udev page in system-config section.</para>
+        </listitem>
+      </itemizedlist>
+    </listitem>
+
+    <listitem>
       <para>19 May 2014</para>
       <itemizedlist>
Index: BOOK/system-config/common/udev.xml
===================================================================
--- BOOK/system-config/common/udev.xml	(revision fab5058225038164452c9cac8081ec5b64470cda)
+++ BOOK/system-config/common/udev.xml	(revision d46b6ed6d06381364935f9e0c62a35fe2d38108e)
@@ -12,72 +12,63 @@
 
   <indexterm zone="ch-scripts-udev">
-    <primary sortas="a-systemd">Systemd</primary>
-    <secondary>udev usage</secondary>
+    <primary sortas="a-Udev">Udev</primary>
+    <secondary>usage</secondary>
   </indexterm>
 
-  <para>In <xref linkend="chapter-building-system"/>, we installed systemd,
-  which contains systemd-udevd, previously known as Udev. 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
-  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
-  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
-  class="filesystem">tmpfs</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>
+  <para>In <xref linkend="chapter-building-system"/>, we installed Udev,
+  as one of the components 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>
 
   <sect2>
     <title>History</title>
 
-    <para>In February 2000, a new filesystem called <systemitem
-    class="filesystem">devfs</systemitem> was merged into the 2.3.46 kernel
-    and was made available during the 2.4 series of stable kernels. Although
-    it was present in the kernel source itself, this method of creating devices
-    dynamically never received overwhelming support from the core kernel
-    developers.</para>
-
-    <para>The main problem with the approach adopted by <systemitem
-    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
-    class="filesystem">devfs</systemitem> file system also suffers from race
-    conditions that are inherent in its design and cannot be fixed without a
-    substantial revision to the kernel. It has also been marked as deprecated
-    due to a lack of recent maintenance.</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
-    the system's hardware configuration to userspace processes. With this
-    userspace-visible representation, the possibility of seeing a userspace
-    replacement for <systemitem class="filesystem">devfs</systemitem> became
-    much more realistic.</para>
-
-  </sect2>
-
-  <sect2>
-    <title>Udev Implementation</title>
+    <sect3>
+      <title>Static Device Nodes</title>
+
+      <para>Linux systems in general traditionally use a static device creation
+      method, whereby a great many device nodes are 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 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>
+
+    </sect3>
+
+    <sect3>
+      <title>Devfs</title>
+
+      <para>In February 2000, a new filesystem called <systemitem
+      class="filesystem">devfs</systemitem> was merged into the 2.3.46 kernel
+      and was made available during the 2.4 series of stable kernels. Although
+      it was present in the kernel source itself, this method of creating devices
+      dynamically never received overwhelming support from the core kernel
+      developers.</para>
+
+      <para>The main problem with the approach adopted by <systemitem
+      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
+      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 deprecated with the
+      release of the 2.6 kernel series, and was removed entirely as of version
+      2.6.18.</para>
+
+    </sect3>
 
     <sect3>
       <title>Sysfs</title>
 
-      <para>The <systemitem class="filesystem">sysfs</systemitem> filesystem 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
+      <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
+      the system's hardware configuration to userspace processes. Drivers that
       have been compiled into the kernel directly register their objects with
       <systemitem class="filesystem">sysfs</systemitem> as they are detected by
@@ -87,73 +78,109 @@
       class="directory">/sys</filename>), data which the built-in drivers
       registered with <systemitem class="filesystem">sysfs</systemitem> are
-      available to userspace processes and to <command>udevd</command> for device
-      node creation.</para>
-
-    </sect3>
-
-    <sect3>
-      <title>Device Node Creation</title>
-
-      <para>To obtain the right major and minor number for a device, Udev relies
-      on the information provided by <systemitem
-      class="filesystem">sysfs</systemitem> in <filename
-      class="directory">/sys</filename>.  For example,
+      available to userspace processes. With this
+      userspace-visible representation, the possibility of seeing a userspace
+      replacement for <systemitem class="filesystem">devfs</systemitem> became
+      much more realistic.</para>
+
+    </sect3>
+
+    <sect3>
+      <title>Udev Implementation</title>
+
+<!--      <title>Device Node Creation</title> -->
+
+      <para>When Udev was introduced, the <command>udevd</command> daemon made
+      calls to mknod() to create device nodes in
+      <filename class="directory">/dev</filename> dynamically, based on the
+      information from <systemitem class="filesystem">sysfs</systemitem>, in
+      <filename class="directory">/sys</filename>. For example,
       <filename>/sys/class/tty/vcs/dev</filename> contains the string
-      <quote>7:0</quote>. This string is used by <command>udevd</command>
-      to create a device node with major number <emphasis>7</emphasis> and minor
-      <emphasis>0</emphasis>. The names and permissions of the nodes created
-      under the <filename class="directory">/dev</filename> directory are
-      determined by rules specified in the files within the
-      <filename class="directory">/lib/udev/rules.d</filename> and <filename
-      class="directory">/etc/udev/rules.d/</filename> directories. These files
-      have names that start with numbers, and are evaluated in numerical order.
-      If <command>udevd</command> can't find a rule for the device it is
-      creating, it will default permissions to <emphasis>660</emphasis> and
-      ownership to <emphasis>root:root</emphasis>. </para>
-
-    </sect3>
-
-    <sect3>
-      <title>Module Loading</title>
-
-      <para>Device drivers compiled as modules may have aliases built into them.
-      Aliases are visible in the output of the <command>modinfo</command>
-      program and are usually related to the bus-specific identifiers of devices
-      supported by a module. For example, the <emphasis>snd-fm801</emphasis>
-      driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801,
-      and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>.
-      For most devices, the bus driver exports the alias of the driver that
-      would handle the device via <systemitem
-      class="filesystem">sysfs</systemitem>. E.g., the
-      <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file
-      might contain the string
-      <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
-      The default rules provided by Udev will cause <command>udevd</command>
-      to call out to <command>/sbin/modprobe</command> with the contents of the
-      <envar>MODALIAS</envar> uevent environment variable (that should be the
-      same as the contents of the <filename>modalias</filename> file in sysfs),
-      thus loading all modules whose aliases match this string after wildcard
-      expansion.</para>
-
-      <para>In this example, this means that, in addition to
-      <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted)
-      <emphasis>forte</emphasis> driver will be loaded if it is
-      available. See below for ways in which the loading of unwanted drivers can
-      be prevented.</para>
-
-      <para>The kernel itself is also able to load modules for network
-      protocols, filesystems and NLS support on demand.</para>
-
-    </sect3>
-
-    <sect3>
-      <title>Handling Hotpluggable/Dynamic Devices</title>
-
-      <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3
-      player, the kernel recognizes that the device is now connected and
-      generates a uevent. This uevent is then handled by
-      <command>udevd</command> as described above.</para>
-
-    </sect3>
+      <quote>7:0</quote>. This string was used by <command>udevd</command>
+      to create a device node with major number <emphasis>7</emphasis> and
+      minor number <emphasis>0</emphasis>. Using the Udev method
+      only those devices which are detected by the kernel would get device
+      nodes created for them. Because these device nodes were created each time
+      the system boots, they were stored on a
+      <systemitem class="filesystem">tmpfs</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>
+
+      <para>Linux kernel version 2.6.32 introduced a new virtual file system
+      called <systemitem class="filesystem">devtmpfs</systemitem>, a
+      replacement for <systemitem class="filesystem">devfs</systemitem>.
+      With this approach, a
+      <systemitem class="filesystem">devtmpfs</systemitem> file system is
+      mounted on <filename class="directory">/dev/</filename> when the system
+      is booted, and all needed device nodes are created on this virtual
+      file system. As of version 176, Udev no longer creates device nodes
+      itself, instead relying on
+      <systemitem class="filesystem">devtmpfs</systemitem> to do so.</para>
+
+      <para>Udev also sets appropriate ownership and permissions
+      for the device nodes, and creates extra symlinks as needed (such as
+      <filename class="symlink">/dev/cdrom</filename>). The ownership and
+      permissions of the nodes under the
+      <filename class="directory">/dev</filename> directory are
+      determined by rules specified in the files within the <filename
+      class="directory">/etc/udev/rules.d/</filename> directory. These are
+      numbered in a similar fashion to the CLFS-Bootscripts package. If
+      <command>udevd</command> can't find a rule for the device it is creating,
+      it will default permissions to <emphasis>660</emphasis> and ownership to
+      <emphasis>root:root</emphasis>.</para>
+
+    </sect3>
+
+    <sect3>
+      <title>Systemd and Eudev</title>
+
+        <para>In May 2012, Udev's source was merged with systemd, an alternate
+        <command>init</command> implementation. Some time later, several Gentoo
+        developers took the Udev code from systemd and created a fork called
+        Eudev.</para>
+
+    </sect3>
+
+  </sect2>
+
+  <sect2>
+    <title>Module Loading</title>
+
+    <para>Device drivers compiled as modules may have aliases built into them.
+    Aliases are visible in the output of the <command>modinfo</command>
+    program and are usually related to the bus-specific identifiers of devices
+    supported by a module. For example, the <emphasis>snd-fm801</emphasis>
+    driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801,
+    and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>.
+    For most devices, the bus driver exports the alias of the driver that
+    would handle the device via <systemitem
+    class="filesystem">sysfs</systemitem>. E.g., the
+    <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file
+    might contain the string
+    <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
+    The default rules provided by Udev will cause <command>udevd</command>
+    to call out to <command>/sbin/modprobe</command> with the contents of the
+    <envar>MODALIAS</envar> uevent environment variable (that should be the
+    same as the contents of the <filename>modalias</filename> file in sysfs),
+    thus loading all modules whose aliases match this string after wildcard
+    expansion.</para>
+
+    <para>In this example, this means that, in addition to
+    <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted)
+    <emphasis>forte</emphasis> driver will be loaded if it is
+    available. See below for ways in which the loading of unwanted drivers can
+    be prevented.</para>
+
+    <para>The kernel itself is also able to load modules for network
+    protocols, filesystems and NLS support on demand.</para>
+
+  </sect2>
+
+  <sect2>
+    <title>Handling Hotpluggable/Dynamic Devices</title>
+
+    <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3
+    player, the kernel recognizes that the device is now connected and
+    generates a uevent. This uevent is then handled by
+    <command>udevd</command> as described above.</para>
 
   </sect2>
@@ -208,10 +235,16 @@
       sound cards available to OSS applications), configure
       <command>modprobe</command> to load the wrapper after Udev loads the
-      wrapped module. To do this, add an <quote>install</quote> line to a file
-      in <filename>/etc/modprobe.d</filename>. For example:</para>
+      wrapped module. To do this, add an <quote>install</quote> line in
+      <filename>/etc/modprobe.conf</filename>. For example:</para>
 
 <screen role="nodump"><literal>install snd-pcm /sbin/modprobe -i snd-pcm ; \
     /sbin/modprobe snd-pcm-oss ; true</literal></screen>
 
+      <para>If the module in question is not a wrapper and is useful by itself,
+      configure the <command>S05modules</command> bootscript to load this
+      module on system boot. To do this, add the module name to the
+      <filename>/etc/sysconfig/modules</filename> file on a separate line.
+      This works for wrapper modules too, but is suboptimal in that case.</para>
+
     </sect3>
 
@@ -220,5 +253,5 @@
 
       <para>Either don't build the module, or blacklist it in
-      <filename>/etc/modprobe.d</filename> file as done with the
+      <filename>/etc/modprobe.conf</filename> file as done with the
       <emphasis>forte</emphasis> module in the example below:</para>
 
@@ -256,25 +289,4 @@
 
     <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>S10udev</command> bootscript.</para>
-
-    </sect3>
-
-    <sect3>
       <title>Device naming order changes randomly after rebooting</title>
 
