[Clfs-commits] [Cross-LFS]Cross-LFS Book branch, master, updated. clfs-2.1.0-1092-gd46b6ed
git
git at cross-lfs.org
Wed May 21 16:34:12 PDT 2014
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Cross-LFS Book".
The branch, master has been updated
via d46b6ed6d06381364935f9e0c62a35fe2d38108e (commit)
from fab5058225038164452c9cac8081ec5b64470cda (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit d46b6ed6d06381364935f9e0c62a35fe2d38108e
Author: Chris Staub <chris at beaker67.com>
Date: Wed May 21 19:34:11 2014 -0400
Rewrote Udev page
diff --git a/BOOK/introduction/common/changelog.xml b/BOOK/introduction/common/changelog.xml
index 9a7b81d..b159769 100644
--- a/BOOK/introduction/common/changelog.xml
+++ b/BOOK/introduction/common/changelog.xml
@@ -37,6 +37,15 @@
-->
<listitem>
+ <para>21 May 2014</para>
+ <itemizedlist>
+ <listitem>
+ <para>[Chris] - Rewrote Udev page in system-config section.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
<para>19 May 2014</para>
<itemizedlist>
<listitem>
diff --git a/BOOK/system-config/common/udev.xml b/BOOK/system-config/common/udev.xml
index fe2af9b..3f4f36d 100644
--- a/BOOK/system-config/common/udev.xml
+++ b/BOOK/system-config/common/udev.xml
@@ -11,74 +11,65 @@
<title>Device and Module Handling on a CLFS System</title>
<indexterm zone="ch-scripts-udev">
- <primary sortas="a-systemd">Systemd</primary>
- <secondary>udev usage</secondary>
+ <primary sortas="a-Udev">Udev</primary>
+ <secondary>usage</secondary>
</indexterm>
- <para>In <xref linkend="chapter-building-system"/>, we installed systemd,
- which contains systemd-udevd, previously known as Udev. Before we go into
- the details regarding how this works, a brief history of previous methods of
- handling devices is in order.</para>
-
- <para>Linux systems in general traditionally use a static device creation
- method, whereby a great many device nodes are created under <filename
- class="directory">/dev</filename> (sometimes literally thousands of nodes),
- regardless of whether the corresponding hardware devices actually exist. This
- is typically done via a <command>MAKEDEV</command> script, which contains a
- number of calls to the <command>mknod</command> program with the relevant
- major and minor device numbers for every possible device that might exist in
- the world.</para>
-
- <para>Using the Udev method, only those devices which are detected by the
- kernel get device nodes created for them. Because these device nodes will be
- created each time the system boots, they will be stored on a <systemitem
- class="filesystem">tmpfs</systemitem> file system (a virtual file system that
- resides entirely in system memory). Device nodes do not require much space, so
- the memory that is used is negligible.</para>
+ <para>In <xref linkend="chapter-building-system"/>, we installed Udev,
+ as one of the components of systemd. Before we go into the details regarding
+ how this works, a brief history of previous methods of handling devices is in
+ order.</para>
<sect2>
<title>History</title>
- <para>In February 2000, a new filesystem called <systemitem
- class="filesystem">devfs</systemitem> was merged into the 2.3.46 kernel
- and was made available during the 2.4 series of stable kernels. Although
- it was present in the kernel source itself, this method of creating devices
- dynamically never received overwhelming support from the core kernel
- developers.</para>
-
- <para>The main problem with the approach adopted by <systemitem
- class="filesystem">devfs</systemitem> was the way it handled device
- detection, creation, and naming. The latter issue, that of device node
- naming, was perhaps the most critical. It is generally accepted that if
- device names are allowed to be configurable, then the device naming policy
- should be up to a system administrator, not imposed on them by any
- particular developer(s). The <systemitem
- class="filesystem">devfs</systemitem> file system also suffers from race
- conditions that are inherent in its design and cannot be fixed without a
- substantial revision to the kernel. It has also been marked as deprecated
- due to a lack of recent maintenance.</para>
-
- <para>With the development of the unstable 2.5 kernel tree, later released
- as the 2.6 series of stable kernels, a new virtual filesystem called
- <systemitem class="filesystem">sysfs</systemitem> came to be. The job of
- <systemitem class="filesystem">sysfs</systemitem> is to export a view of
- the system's hardware configuration to userspace processes. With this
- userspace-visible representation, the possibility of seeing a userspace
- replacement for <systemitem class="filesystem">devfs</systemitem> became
- much more realistic.</para>
+ <sect3>
+ <title>Static Device Nodes</title>
- </sect2>
+ <para>Linux systems in general traditionally use a static device creation
+ method, whereby a great many device nodes are created under <filename
+ class="directory">/dev</filename> (sometimes literally thousands of nodes),
+ regardless of whether the corresponding hardware devices actually exist.
+ This is typically done via a <command>MAKEDEV</command> script, which
+ contains a number of calls to the <command>mknod</command> program with the
+ relevant major and minor device numbers for every possible device that
+ might exist in the world.</para>
- <sect2>
- <title>Udev Implementation</title>
+ </sect3>
+
+ <sect3>
+ <title>Devfs</title>
+
+ <para>In February 2000, a new filesystem called <systemitem
+ class="filesystem">devfs</systemitem> was merged into the 2.3.46 kernel
+ and was made available during the 2.4 series of stable kernels. Although
+ it was present in the kernel source itself, this method of creating devices
+ dynamically never received overwhelming support from the core kernel
+ developers.</para>
+
+ <para>The main problem with the approach adopted by <systemitem
+ class="filesystem">devfs</systemitem> was the way it handled device
+ detection, creation, and naming. The latter issue, that of device node
+ naming, was perhaps the most critical. It is generally accepted that if
+ device names are allowed to be configurable, then the device naming policy
+ should be up to a system administrator, not imposed on them by any
+ particular developer(s). The <systemitem
+ class="filesystem">devfs</systemitem> file system also suffered from race
+ conditions that were inherent in its design and could not be fixed without a
+ substantial revision to the kernel. It was marked deprecated with the
+ release of the 2.6 kernel series, and was removed entirely as of version
+ 2.6.18.</para>
+
+ </sect3>
<sect3>
<title>Sysfs</title>
- <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
+ <para>With the development of the unstable 2.5 kernel tree, later released
+ as the 2.6 series of stable kernels, a new virtual filesystem called
+ <systemitem class="filesystem">sysfs</systemitem> came to be. The job of
+ <systemitem class="filesystem">sysfs</systemitem> is to export a view of
+ the system's hardware configuration to userspace processes. 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
@@ -86,75 +77,111 @@
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 device
- node creation.</para>
+ available to userspace processes. With this
+ userspace-visible representation, the possibility of seeing a userspace
+ replacement for <systemitem class="filesystem">devfs</systemitem> became
+ much more realistic.</para>
</sect3>
<sect3>
- <title>Device Node Creation</title>
+ <title>Udev Implementation</title>
+
+<!-- <title>Device Node Creation</title> -->
- <para>To obtain the right major and minor number for a device, Udev relies
- on the information provided by <systemitem
- class="filesystem">sysfs</systemitem> in <filename
- class="directory">/sys</filename>. For example,
+ <para>When Udev was introduced, the <command>udevd</command> daemon made
+ calls to mknod() to create device nodes in
+ <filename class="directory">/dev</filename> dynamically, based on the
+ information from <systemitem class="filesystem">sysfs</systemitem>, in
+ <filename class="directory">/sys</filename>. For example,
<filename>/sys/class/tty/vcs/dev</filename> contains the string
- <quote>7:0</quote>. This string is used by <command>udevd</command>
- to create a device node with major number <emphasis>7</emphasis> and minor
- <emphasis>0</emphasis>. The names and permissions of the nodes created
- under the <filename class="directory">/dev</filename> directory are
- determined by rules specified in the files within the
- <filename class="directory">/lib/udev/rules.d</filename> and <filename
- class="directory">/etc/udev/rules.d/</filename> directories. These files
- have names that start with numbers, and are evaluated in numerical order.
- If <command>udevd</command> can't find a rule for the device it is
- creating, it will default permissions to <emphasis>660</emphasis> and
- ownership to <emphasis>root:root</emphasis>. </para>
+ <quote>7:0</quote>. This string was used by <command>udevd</command>
+ to create a device node with major number <emphasis>7</emphasis> and
+ minor number <emphasis>0</emphasis>. Using the Udev method
+ only those devices which are detected by the kernel would get device
+ nodes created for them. Because these device nodes were created each time
+ the system boots, they were stored on a
+ <systemitem class="filesystem">tmpfs</systemitem> file system (a virtual
+ file system that resides entirely in system memory). Device nodes do not
+ require much space, so the memory that is used is negligible.</para>
+
+ <para>Linux kernel version 2.6.32 introduced a new virtual file system
+ called <systemitem class="filesystem">devtmpfs</systemitem>, a
+ replacement for <systemitem class="filesystem">devfs</systemitem>.
+ With this approach, a
+ <systemitem class="filesystem">devtmpfs</systemitem> file system is
+ mounted on <filename class="directory">/dev/</filename> when the system
+ is booted, and all needed device nodes are created on this virtual
+ file system. As of version 176, Udev no longer creates device nodes
+ itself, instead relying on
+ <systemitem class="filesystem">devtmpfs</systemitem> to do so.</para>
+
+ <para>Udev also sets appropriate ownership and permissions
+ for the device nodes, and creates extra symlinks as needed (such as
+ <filename class="symlink">/dev/cdrom</filename>). The ownership and
+ permissions of the nodes under the
+ <filename class="directory">/dev</filename> directory are
+ determined by rules specified in the files within the <filename
+ class="directory">/etc/udev/rules.d/</filename> directory. These are
+ numbered in a similar fashion to the CLFS-Bootscripts package. If
+ <command>udevd</command> can't find a rule for the device it is creating,
+ it will default permissions to <emphasis>660</emphasis> and ownership to
+ <emphasis>root:root</emphasis>.</para>
</sect3>
<sect3>
- <title>Module Loading</title>
-
- <para>Device drivers compiled as modules may have aliases built into them.
- Aliases are visible in the output of the <command>modinfo</command>
- program and are usually related to the bus-specific identifiers of devices
- supported by a module. For example, the <emphasis>snd-fm801</emphasis>
- driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801,
- and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>.
- For most devices, the bus driver exports the alias of the driver that
- would handle the device via <systemitem
- class="filesystem">sysfs</systemitem>. E.g., the
- <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file
- might contain the string
- <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
- The default rules provided by Udev will cause <command>udevd</command>
- to call out to <command>/sbin/modprobe</command> with the contents of the
- <envar>MODALIAS</envar> uevent environment variable (that should be the
- same as the contents of the <filename>modalias</filename> file in sysfs),
- thus loading all modules whose aliases match this string after wildcard
- expansion.</para>
-
- <para>In this example, this means that, in addition to
- <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted)
- <emphasis>forte</emphasis> driver will be loaded if it is
- available. See below for ways in which the loading of unwanted drivers can
- be prevented.</para>
-
- <para>The kernel itself is also able to load modules for network
- protocols, filesystems and NLS support on demand.</para>
+ <title>Systemd and Eudev</title>
+
+ <para>In May 2012, Udev's source was merged with systemd, an alternate
+ <command>init</command> implementation. Some time later, several Gentoo
+ developers took the Udev code from systemd and created a fork called
+ Eudev.</para>
</sect3>
- <sect3>
- <title>Handling Hotpluggable/Dynamic Devices</title>
+ </sect2>
- <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3
- player, the kernel recognizes that the device is now connected and
- generates a uevent. This uevent is then handled by
- <command>udevd</command> as described above.</para>
+ <sect2>
+ <title>Module Loading</title>
+
+ <para>Device drivers compiled as modules may have aliases built into them.
+ Aliases are visible in the output of the <command>modinfo</command>
+ program and are usually related to the bus-specific identifiers of devices
+ supported by a module. For example, the <emphasis>snd-fm801</emphasis>
+ driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801,
+ and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>.
+ For most devices, the bus driver exports the alias of the driver that
+ would handle the device via <systemitem
+ class="filesystem">sysfs</systemitem>. E.g., the
+ <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file
+ might contain the string
+ <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
+ The default rules provided by Udev will cause <command>udevd</command>
+ to call out to <command>/sbin/modprobe</command> with the contents of the
+ <envar>MODALIAS</envar> uevent environment variable (that should be the
+ same as the contents of the <filename>modalias</filename> file in sysfs),
+ thus loading all modules whose aliases match this string after wildcard
+ expansion.</para>
+
+ <para>In this example, this means that, in addition to
+ <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted)
+ <emphasis>forte</emphasis> driver will be loaded if it is
+ available. See below for ways in which the loading of unwanted drivers can
+ be prevented.</para>
+
+ <para>The kernel itself is also able to load modules for network
+ protocols, filesystems and NLS support on demand.</para>
- </sect3>
+ </sect2>
+
+ <sect2>
+ <title>Handling Hotpluggable/Dynamic Devices</title>
+
+ <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3
+ player, the kernel recognizes that the device is now connected and
+ generates a uevent. This uevent is then handled by
+ <command>udevd</command> as described above.</para>
</sect2>
@@ -207,19 +234,25 @@
enhances the functionality of <emphasis>snd-pcm</emphasis> by making the
sound cards available to OSS applications), configure
<command>modprobe</command> to load the wrapper after Udev loads the
- wrapped module. To do this, add an <quote>install</quote> line to a file
- in <filename>/etc/modprobe.d</filename>. For example:</para>
+ wrapped module. To do this, add an <quote>install</quote> line in
+ <filename>/etc/modprobe.conf</filename>. For example:</para>
<screen role="nodump"><literal>install snd-pcm /sbin/modprobe -i snd-pcm ; \
/sbin/modprobe snd-pcm-oss ; true</literal></screen>
+ <para>If the module in question is not a wrapper and is useful by itself,
+ configure the <command>S05modules</command> bootscript to load this
+ module on system boot. To do this, add the module name to the
+ <filename>/etc/sysconfig/modules</filename> file on a separate line.
+ This works for wrapper modules too, but is suboptimal in that case.</para>
+
</sect3>
<sect3>
<title>Udev loads some unwanted module</title>
<para>Either don't build the module, or blacklist it in
- <filename>/etc/modprobe.d</filename> file as done with the
+ <filename>/etc/modprobe.conf</filename> file as done with the
<emphasis>forte</emphasis> module in the example below:</para>
<screen role="nodump"><literal>blacklist forte</literal></screen>
@@ -255,27 +288,6 @@
</sect3>
<sect3>
- <title>Udev does not create a device</title>
-
- <para>Further text assumes that the driver is built statically into the
- kernel or already loaded as a module, and that you have already checked
- that Udev doesn't create a misnamed device.</para>
-
- <para>Udev has no information needed to create a device node if a kernel
- driver does not export its data to <systemitem
- class="filesystem">sysfs</systemitem>.
- This is most common with third party drivers from outside the kernel
- tree. Create a static device node in
- <filename>/lib/udev/devices</filename> with the appropriate major/minor
- numbers (see the file <filename>devices.txt</filename> inside the kernel
- documentation or the documentation provided by the third party driver
- vendor). The static device node will be copied to
- <filename class="directory">/dev</filename> by the
- <command>S10udev</command> bootscript.</para>
-
- </sect3>
-
- <sect3>
<title>Device naming order changes randomly after rebooting</title>
<para>This is due to the fact that Udev, by design, handles uevents and
-----------------------------------------------------------------------
Summary of changes:
BOOK/introduction/common/changelog.xml | 9 +
BOOK/system-config/common/udev.xml | 280 +++++++++++++++++---------------
2 files changed, 155 insertions(+), 134 deletions(-)
hooks/post-receive
--
Cross-LFS Book
More information about the Clfs-commits
mailing list