Changeset 76b06f6 for BOOK/bootscripts/common/udev.xml

Timestamp:

Sep 24, 2013, 11:53:17 AM (11 years ago)

Author:

William Harrington <kb0iic@…>

Children:

2e9ccbe

Parents:

111b12a

Message:

Prepare for CLFS-2.0.0 release.

File:

• BOOK/bootscripts/common/udev.xml (moved) (moved from BOOK/bootscripts/common/eudev.xml) (18 diffs)

BOOK/bootscripts/common/udev.xml

@@ -6 +6 @@
 ]>
 
-<sect1 id="ch-scripts-eudev">
-  <?dbhtml filename="eudev.html"?>
+<sect1 id="ch-scripts-udev">
+  <?dbhtml filename="udev.html"?>
 
   <title>Device and Module Handling on a CLFS System</title>
 
-  <indexterm zone="ch-scripts-eudev">
-    <primary sortas="a-Eudev">Eudev</primary>
+  <indexterm zone="ch-scripts-udev">
+    <primary sortas="a-Udev">Udev</primary>
     <secondary>usage</secondary>
   </indexterm>
 
-  <para>In <xref linkend="chapter-building-system"/>, we installed the Eudev
+  <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
@@ -30 +30 @@
   the world.</para>
 
-  <para>Using the Eudev method, only those devices which are detected by the
+  <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
@@ -71 +71 @@
 
   <sect2>
-    <title>Eudev Implementation</title>
+    <title>Udev Implementation</title>
 
     <sect3>
@@ -93 +93 @@
 
     <sect3>
-      <title>Eudev Bootscript</title>
+      <title>Udev Bootscript</title>
 
       <para>The <command>S10udev</command> initscript takes care of creating
@@ -109 +109 @@
       class="directory">/lib/udev/devices</filename> also provides an easy
       workaround for devices that are not supported by the dynamic device
-      handling infrastructure. The bootscript then starts the Eudev daemon,
+      handling infrastructure. The bootscript then starts the Udev daemon,
       <command>udevd</command>, which will act on any uevents it receives.
       Finally, the bootscript forces the kernel to replay uevents for any
@@ -120 +120 @@
       <title>Device Node Creation</title>
 
-      <para>To obtain the right major and minor number for a device, Eudev relies
+      <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
@@ -134 +134 @@
       <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>. Documentation on the syntax of the Eudev
+      <emphasis>root:root</emphasis>. Documentation on the syntax of the Udev
       rules configuration files is available in
       <filename>/usr/share/doc/udev/writing_udev_rules/index.html</filename></para>
@@ -155 +155 @@
       might contain the string
       <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
-      The default rules provided by Eudev will cause <command>udevd</command>
+      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
@@ -194 +194 @@
       <title>A kernel module is not loaded automatically</title>
 
-      <para>Eudev will only load a module if it has a bus-specific alias and the
+      <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
       class="filesystem">sysfs</systemitem>. In other cases, one should
-      arrange module loading by other means. With Linux-&linux-version;, Eudev is
+      arrange module loading by other means. With Linux-&linux-version;, Udev is
       known to load properly-written drivers for INPUT, IDE, PCI, USB, SCSI,
       SERIO and FireWire devices.</para>
 
       <para>To determine if the device driver you require has the necessary
-      support for Eudev, run <command>modinfo</command> with the module name as
+      support for Udev, run <command>modinfo</command> with the module name as
       the argument.  Now try locating the device directory under
       <filename class="directory">/sys/bus</filename> and check whether there is
@@ -210 +210 @@
       class="filesystem">sysfs</systemitem>, the driver supports the device and
       can talk to it directly, but doesn't have the alias, it is a bug in the
-      driver. Load the driver without the help from Eudev and expect the issue
+      driver. Load the driver without the help from Udev and expect the issue
       to be fixed later.</para>
 
@@ -219 +219 @@
       busses. Expect this issue to be fixed in later kernel versions.</para>
 
-      <para>Eudev is not intended to load <quote>wrapper</quote> drivers such as
+      <para>Udev is not intended to load <quote>wrapper</quote> drivers such as
       <emphasis>snd-pcm-oss</emphasis> and non-hardware drivers such as
       <emphasis>loop</emphasis> at all.</para>
@@ -226 +226 @@
 
     <sect3>
-      <title>A kernel module is not loaded automatically, and Eudev is not
+      <title>A kernel module is not loaded automatically, and Udev is not
       intended to load it</title>
 
@@ -233 +233 @@
       enhances the functionality of <emphasis>snd-pcm</emphasis> by making the
       sound cards available to OSS applications), configure
-      <command>modprobe</command> to load the wrapper after Eudev loads the
+      <command>modprobe</command> to load the wrapper after Udev loads the
       wrapped module. To do this, add an <quote>install</quote> line in
       <filename>/etc/modprobe.conf</filename>. For example:</para>
@@ -249 +249 @@
 
     <sect3>
-      <title>Eudev loads some unwanted module</title>
+      <title>Udev loads some unwanted module</title>
 
       <para>Either don't build the module, or blacklist it in
@@ -263 +263 @@
 
     <sect3>
-      <title>Eudev creates a device incorrectly, or makes a wrong symlink</title>
+      <title>Udev creates a device incorrectly, or makes a wrong symlink</title>
 
       <para>This usually happens if a rule unexpectedly matches a device. For
@@ -274 +274 @@
 
     <sect3>
-      <title>Eudev rule works unreliably</title>
+      <title>Udev rule works unreliably</title>
 
       <para>This may be another manifestation of the previous problem. If not,
@@ -288 +288 @@
 
     <sect3>
-      <title>Eudev 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 Eudev doesn't create a misnamed device.</para>
-
-      <para>Eudev has no information needed to create a device node if a kernel
+      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>.
@@ -311 +311 @@
       <title>Device naming order changes randomly after rebooting</title>
 
-      <para>This is due to the fact that Eudev, by design, handles uevents and
+      <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
       never be <quote>fixed</quote>. You should not rely upon the kernel device
       names being stable. Instead, create your own rules that make symlinks with
       stable names based on some stable attributes of the device, such as a
-      serial number or the output of various *_id utilities installed by Eudev.
+      serial number or the output of various *_id utilities installed by Udev.
       See <xref linkend="ch-scripts-symlinks"/> and
       <xref linkend="chapter-network"/> for examples.</para>