Update udev explanation.

Be consistent with ln options.


git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@10015 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Bruce Dubbs 2012-10-02 22:40:39 +00:00
parent ce935eba24
commit 5cef3143bf
4 changed files with 62 additions and 61 deletions

View File

@ -86,7 +86,7 @@
<para>Make a link for the programs that use <command>sh</command> for <para>Make a link for the programs that use <command>sh</command> for
a shell:</para> 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> </sect2>

View File

@ -238,7 +238,7 @@ cd ../gcc-build</userinput></screen>
since that file will end up containing the objects normally contained in since that file will end up containing the objects normally contained in
<filename>libgcc_eh.a</filename>:</para> <filename>libgcc_eh.a</filename>:</para>
<screen><userinput remap="install">ln -vs libgcc.a `$LFS_TGT-gcc -print-libgcc-file-name | sed 's/libgcc/&amp;_eh/'`</userinput></screen> <screen><userinput remap="install">ln -sv libgcc.a `$LFS_TGT-gcc -print-libgcc-file-name | sed 's/libgcc/&amp;_eh/'`</userinput></screen>
</sect2> </sect2>

View File

@ -210,7 +210,7 @@ RANLIB=$LFS_TGT-ranlib \
<command>cc</command> leaves the system administrator free to decide <command>cc</command> leaves the system administrator free to decide
which C compiler to install:</para> 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> <caution>
<para>At this point, it is imperative to stop and ensure that the basic <para>At this point, it is imperative to stop and ensure that the basic

View File

@ -76,87 +76,87 @@
<sect3> <sect3>
<title>Sysfs</title> <title>Sysfs</title>
<para>The <systemitem class="filesystem">sysfs</systemitem> filesystem was <para>The <systemitem class="filesystem">sysfs</systemitem> filesystem
mentioned briefly above. One may wonder how <systemitem was mentioned briefly above. One may wonder how <systemitem
class="filesystem">sysfs</systemitem> knows about the devices present on class="filesystem">sysfs</systemitem> knows about the devices present on
a system and what device numbers should be used for them. Drivers that a system and what device numbers should be used for them. Drivers that
have been compiled into the kernel directly register their objects with have been compiled into the kernel directly register their objects with a
<systemitem class="filesystem">sysfs</systemitem> as they are detected by <systemitem class="filesystem">sysfs</systemitem> (devtmpfs internally)
the kernel. For drivers compiled as modules, this registration will happen as they are detected by the kernel. For drivers compiled as modules, this
when the module is loaded. Once the <systemitem registration will happen when the module is loaded. Once the <systemitem
class="filesystem">sysfs</systemitem> filesystem is mounted (on <filename class="filesystem">sysfs</systemitem> filesystem is mounted (on /sys),
class="directory">/sys</filename>), data which the built-in drivers data which the drivers register with <systemitem
registered with <systemitem class="filesystem">sysfs</systemitem> are class="filesystem">sysfs</systemitem> are available to userspace
available to userspace processes and to <command>udevd</command> for processes and to udevd for processing (including modifications to device
processing (including modifications to device nodes).</para> 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>
<sect3> <sect3>
<title>Device Node Creation</title> <title>Device Node Creation</title>
<para>In recent version of udev, <command>udevd</command> no longer <para>Device files are created by the kernel by the <systemitem
creates device files in <filename class="directory">/dev</filename>.
Instead, this must be handled in the kernel, by the <systemitem
class="filesystem">devtmpfs</systemitem> filesystem. Any driver that 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 <systemitem
class="filesystem">devtmpfs</systemitem> (via the driver core) to do it. class="filesystem">devtmpfs</systemitem> (via the driver core) to do it.
When a <systemitem class="filesystem">devtmpfs</systemitem> instance is When a <systemitem class="filesystem">devtmpfs</systemitem> instance is
mounted on <filename class="directory">/dev</filename>, the device node 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> <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 udevd</command>. Based on the rules specified in the files within the
<filename class="directory">/etc/udev/rules.d</filename>, <filename <filename class="directory">/etc/udev/rules.d</filename>, <filename
class="directory">/lib/udev/rules.d</filename>, and <filename class="directory">/lib/udev/rules.d</filename>, and <filename
class="directory">/run/udev/rules.d</filename> directories, <command> class="directory">/run/udev/rules.d</filename> directories, <command>
udevd</command> will create additional symlinks to the device node, udevd</command> will create additional symlinks to the device node, or
or change its permissions, owner, or group, or modify the internal change its permissions, owner, or group, or modify the internal
<command>udevd</command> database entry for that object.</para> <command>udevd</command> database entry (name) for that object.</para>
<para>The rules in these three directories are numbered in a similar <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 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 device it is creating, it will leave the permissions and ownership at
whatever <systemitem class="filesystem">devtmpfs</systemitem> used 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 &lt;device&gt;</command> where
&lt;device&gt; 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> <ulink url="http://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/mochel.pdf"/></para>
</listitem> </listitem>
<!-- No longer available
<listitem> <listitem>
<para>Pointers to further reading <para>Pointers to further reading
<ulink url="http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html"/> <ulink url="http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html"/>
</para> </para>
</listitem> </listitem>
-->
</itemizedlist> </itemizedlist>
</sect2> </sect2>