[lfs-book] r10015 - in trunk/BOOK: chapter05 chapter07

bdubbs at linuxfromscratch.org bdubbs at linuxfromscratch.org
Tue Oct 2 15:40:43 PDT 2012


Author: bdubbs
Date: 2012-10-02 16:40:39 -0600 (Tue, 02 Oct 2012)
New Revision: 10015

Modified:
   trunk/BOOK/chapter05/bash.xml
   trunk/BOOK/chapter05/gcc-pass1.xml
   trunk/BOOK/chapter05/gcc-pass2.xml
   trunk/BOOK/chapter07/udev.xml
Log:
Update udev explanation.
Be consistent with ln options.


Modified: trunk/BOOK/chapter05/bash.xml
===================================================================
--- trunk/BOOK/chapter05/bash.xml	2012-10-02 20:07:42 UTC (rev 10014)
+++ trunk/BOOK/chapter05/bash.xml	2012-10-02 22:40:39 UTC (rev 10015)
@@ -86,7 +86,7 @@
     <para>Make a link for the programs that use <command>sh</command> for
     a shell:</para>
 
-<screen><userinput remap="install">ln -vs bash /tools/bin/sh</userinput></screen>
+<screen><userinput remap="install">ln -sv bash /tools/bin/sh</userinput></screen>
 
   </sect2>
 

Modified: trunk/BOOK/chapter05/gcc-pass1.xml
===================================================================
--- trunk/BOOK/chapter05/gcc-pass1.xml	2012-10-02 20:07:42 UTC (rev 10014)
+++ trunk/BOOK/chapter05/gcc-pass1.xml	2012-10-02 22:40:39 UTC (rev 10015)
@@ -238,7 +238,7 @@
     since that file will end up containing the objects normally contained in
     <filename>libgcc_eh.a</filename>:</para>
 
-<screen><userinput remap="install">ln -vs libgcc.a `$LFS_TGT-gcc -print-libgcc-file-name | sed 's/libgcc/&_eh/'`</userinput></screen>
+<screen><userinput remap="install">ln -sv libgcc.a `$LFS_TGT-gcc -print-libgcc-file-name | sed 's/libgcc/&_eh/'`</userinput></screen>
 
   </sect2>
 

Modified: trunk/BOOK/chapter05/gcc-pass2.xml
===================================================================
--- trunk/BOOK/chapter05/gcc-pass2.xml	2012-10-02 20:07:42 UTC (rev 10014)
+++ trunk/BOOK/chapter05/gcc-pass2.xml	2012-10-02 22:40:39 UTC (rev 10015)
@@ -210,7 +210,7 @@
     <command>cc</command> leaves the system administrator free to decide
     which C compiler to install:</para>
 
-<screen><userinput remap="install">ln -vs gcc /tools/bin/cc</userinput></screen>
+<screen><userinput remap="install">ln -sv gcc /tools/bin/cc</userinput></screen>
 
   <caution>
     <para>At this point, it is imperative to stop and ensure that the basic

Modified: trunk/BOOK/chapter07/udev.xml
===================================================================
--- trunk/BOOK/chapter07/udev.xml	2012-10-02 20:07:42 UTC (rev 10014)
+++ trunk/BOOK/chapter07/udev.xml	2012-10-02 22:40:39 UTC (rev 10015)
@@ -76,88 +76,88 @@
     <sect3>
       <title>Sysfs</title>
 
-      <para>The <systemitem class="filesystem">sysfs</systemitem> filesystem was
-      mentioned briefly above. One may wonder how <systemitem
+      <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
-      have been compiled into the kernel directly register their objects with
-      <systemitem class="filesystem">sysfs</systemitem> as they are detected by
-      the kernel. For drivers compiled as modules, this registration will happen
-      when the module is loaded. Once the <systemitem
-      class="filesystem">sysfs</systemitem> filesystem is mounted (on <filename
-      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
-      processing (including modifications to device nodes).</para>
+      have been compiled into the kernel directly register their objects with a
+      <systemitem class="filesystem">sysfs</systemitem> (devtmpfs internally)
+      as they are detected by the kernel. For drivers compiled as modules, this
+      registration will happen when the module is loaded. Once the <systemitem
+      class="filesystem">sysfs</systemitem> filesystem is mounted (on /sys),
+      data which the drivers register with <systemitem
+      class="filesystem">sysfs</systemitem> are available to userspace
+      processes and to udevd for processing (including modifications to device
+      nodes).</para> 
 
     </sect3>
 
     <sect3>
-      <title>Udev Bootscripts</title>
-
-      <para>The <command>/etc/rc.d/init.d/udev</command> initscript takes care
-      of creating device nodes when Linux is booted. The script unsets the
-      uevent handler from the default of <command>/sbin/hotplug</command>.
-      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. Next, the bootscript
-      copies any static device nodes that exist 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. 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
-      devices that have already been registered and then waits for
-      <command>udevd</command> to handle them.</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, /usr and /var 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</command>.)</para>
-
-    </sect3>
-
-    <sect3>
       <title>Device Node Creation</title>
 
-      <para>In recent version of udev, <command>udevd</command> no longer
-      creates device files in <filename class="directory">/dev</filename>.
-      Instead, this must be handled in the kernel, by the <systemitem
+      <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
       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 owner.</para>
+      will initially be created with a fixed name, permissions, and
+      owner.</para>
 
       <para>A short time later, the kernel will send a uevent to <command>
       udevd</command>.  Based on the rules specified in the files within the
       <filename class="directory">/etc/udev/rules.d</filename>, <filename
       class="directory">/lib/udev/rules.d</filename>, and <filename
       class="directory">/run/udev/rules.d</filename> directories, <command>
-      udevd</command> will create additional symlinks to the device node,
-      or change its permissions, owner, or group, or modify the internal
-      <command>udevd</command> database entry for that object.</para>
+      udevd</command> will create additional symlinks to the device node, or
+      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
+      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>
+      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 <device></command> where
+      <device> is a an absolure path in /dev or /sys such as /dev/sr0 or
+      /sys/class/rtc.</para>
+
     </sect3>
 
     <sect3>
@@ -368,12 +368,13 @@
         <ulink url="http://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/mochel.pdf"/></para>
       </listitem>
 
+<!--  No longer available
       <listitem>
         <para>Pointers to further reading
         <ulink url="http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html"/>
         </para>
       </listitem>
-
+-->
     </itemizedlist>
 
   </sect2>




More information about the lfs-book mailing list