diff options
Diffstat (limited to 'chapter07/udev.xml')
| -rw-r--r-- | chapter07/udev.xml | 96 |
1 files changed, 17 insertions, 79 deletions
diff --git a/chapter07/udev.xml b/chapter07/udev.xml index 7e11388d8..f8a73d8e9 100644 --- a/chapter07/udev.xml +++ b/chapter07/udev.xml @@ -8,7 +8,7 @@ <sect1 id="ch-scripts-udev"> <?dbhtml filename="udev.html"?> - <title>Device and Module Handling on an LFS System</title> + <title>Overview of Device and Module Handling</title> <indexterm zone="ch-scripts-udev"> <primary sortas="a-Udev">Udev</primary> @@ -16,15 +16,15 @@ </indexterm> <para>In <xref linkend="chapter-building-system"/>, we installed the Udev - package. Before we go into the details regarding how this works, - a brief history of previous methods of handling devices is in + package as a part 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> - <para>Linux systems in general traditionally use a static device creation - method, whereby a great many device nodes are created under <filename + <para>Linux systems in general traditionally used a static device creation + method, whereby a great many device nodes were 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 + regardless of whether the corresponding hardware devices actually existed. This + was 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> @@ -53,8 +53,8 @@ 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 + 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 as deprecated for a long period – due to a lack of maintenance – and was finally removed from the kernel in June, 2006.</para> @@ -64,7 +64,7 @@ <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 + userspace-visible representation, the possibility of developing a userspace replacement for <systemitem class="filesystem">devfs</systemitem> became much more realistic.</para> @@ -97,7 +97,7 @@ <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 + wishes to register a device node will go through the <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 @@ -113,53 +113,12 @@ 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 - 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> </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 an absolute path in /dev or /sys such as /dev/sr0 or - /sys/class/rtc.</para> - - </sect3> - + <para>The rules in these three directories are numbered 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> </sect3> + <sect3> <title>Module Loading</title> @@ -314,27 +273,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>udev</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 |