diff options
| -rw-r--r-- | chapter05/bash.xml | 2 | ||||
| -rw-r--r-- | chapter05/gcc-pass1.xml | 2 | ||||
| -rw-r--r-- | chapter05/gcc-pass2.xml | 2 | ||||
| -rw-r--r-- | chapter07/udev.xml | 117 |
4 files changed, 62 insertions, 61 deletions
diff --git a/chapter05/bash.xml b/chapter05/bash.xml index db5d5b4d7..60957b9c1 100644 --- a/chapter05/bash.xml +++ b/chapter05/bash.xml @@ -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> diff --git a/chapter05/gcc-pass1.xml b/chapter05/gcc-pass1.xml index 0edcd87d2..b7f97a386 100644 --- a/chapter05/gcc-pass1.xml +++ b/chapter05/gcc-pass1.xml @@ -238,7 +238,7 @@ cd ../gcc-build</userinput></screen> 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> diff --git a/chapter05/gcc-pass2.xml b/chapter05/gcc-pass2.xml index ee09e026c..9bbca7839 100644 --- a/chapter05/gcc-pass2.xml +++ b/chapter05/gcc-pass2.xml @@ -210,7 +210,7 @@ RANLIB=$LFS_TGT-ranlib \ <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 diff --git a/chapter07/udev.xml b/chapter07/udev.xml index 1d65a221f..b8a8bc8cb 100644 --- a/chapter07/udev.xml +++ b/chapter07/udev.xml @@ -76,87 +76,87 @@ <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> - - </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> + 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>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> @@ -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> |