mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-06-19 03:39:20 +01:00
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
parent
ce935eba24
commit
5cef3143bf
@ -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>
|
||||
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user