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:
parent
ce935eba24
commit
5cef3143bf
@ -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>
|
||||||
|
|
||||||
|
@ -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/&_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>
|
</sect2>
|
||||||
|
|
||||||
|
@ -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
|
||||||
|
@ -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 <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>
|
<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>
|
||||||
|
Loading…
Reference in New Issue
Block a user