#: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:11 msgid "Overview of Device and Module Handling" msgstr "" #. type: Content of: <sect1><indexterm><primary> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:14 msgid "Udev" msgstr "" #. type: Content of: <sect1><indexterm><secondary> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:15 msgid "usage" msgstr "" #. type: Content of: <sect1><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:18 msgid "" "In <xref linkend=\"chapter-building-system\"/>, we installed the udev " "package when <phrase revision=\"sysv\">eudev</phrase> <phrase " "revision=\"systemd\">systemd</phrase> was built. Before we go into the " "details regarding how this works, a brief history of previous methods of " "handling devices is in order." msgstr "" #. type: Content of: <sect1><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:24 msgid "" "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 " "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." msgstr "" #. type: Content of: <sect1><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:33 msgid "" "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\">devtmpfs</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." msgstr "" #. type: Content of: <sect1><sect2><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:41 msgid "History" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:43 msgid "" "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." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:50 msgid "" "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 as deprecated for a long " "period – due to a lack of maintenance – and was finally removed " "from the kernel in June, 2006." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:63 msgid "" "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 developing a userspace replacement for " "<systemitem class=\"filesystem\">devfs</systemitem> became much more " "realistic." msgstr "" #. type: Content of: <sect1><sect2><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:75 msgid "Udev Implementation" msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:78 msgid "Sysfs" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:80 msgid "" "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 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)." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:97 msgid "Device Node Creation" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:99 msgid "" "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 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 " "will initially be created with a fixed name, permissions, and owner." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:108 msgid "" "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 (name) for that object." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:117 msgid "" "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." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:124 msgid "Module Loading" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:126 msgid "" "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 with 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 (which 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." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:145 msgid "" "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." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:151 msgid "" "The kernel itself is also able to load modules for network protocols, " "filesystems, and NLS support on demand." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:157 msgid "Handling Hotpluggable/Dynamic Devices" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:159 msgid "" "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." msgstr "" #. type: Content of: <sect1><sect2><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:169 msgid "Problems with Loading Modules and Creating Devices" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:171 msgid "" "There are a few possible problems when it comes to automatically creating " "device nodes." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:175 msgid "A kernel module is not loaded automatically" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:177 msgid "" "Udev will only load a module if it has a bus-specific alias and the bus " "driver properly exports the necessary aliases to <systemitem " "class=\"filesystem\">sysfs</systemitem>. In other cases, one should arrange " "module loading by other means. With Linux-&linux-version;, udev is known to " "load properly-written drivers for INPUT, IDE, PCI, USB, SCSI, SERIO, and " "FireWire devices." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:184 msgid "" "To determine if the device driver you require has the necessary support for " "udev, run <command>modinfo</command> with the module name as the argument. " "Now try locating the device directory under <filename " "class=\"directory\">/sys/bus</filename> and check whether there is a " "<filename>modalias</filename> file there." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:190 msgid "" "If the <filename>modalias</filename> file exists in <systemitem " "class=\"filesystem\">sysfs</systemitem>, the driver supports the device and " "can talk to it directly, but doesn't have the alias, it is a bug in the " "driver. Load the driver without the help from udev and expect the issue to " "be fixed later." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:196 msgid "" "If there is no <filename>modalias</filename> file in the relevant directory " "under <filename class=\"directory\">/sys/bus</filename>, this means that the " "kernel developers have not yet added modalias support to this bus type. With " "Linux-&linux-version;, this is the case with ISA busses. Expect this issue " "to be fixed in later kernel versions." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:202 msgid "" "Udev is not intended to load <quote>wrapper</quote> drivers such as " "<emphasis>snd-pcm-oss</emphasis> and non-hardware drivers such as " "<emphasis>loop</emphasis> at all." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:209 msgid "" "A kernel module is not loaded automatically, and udev is not intended to " "load it" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:212 msgid "" "If the <quote>wrapper</quote> module only enhances the functionality " "provided by some other module (e.g., <emphasis>snd-pcm-oss</emphasis> " "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 a <quote>softdep</quote> line to the corresponding " "<filename>/etc/modprobe.d/<replaceable><filename></replaceable>.conf</filename> " "file. For example:" msgstr "" #. type: Content of: <sect1><sect2><sect3><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:222 #, no-wrap msgid "<literal>softdep snd-pcm post: snd-pcm-oss</literal>" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:224 msgid "" "Note that the <quote>softdep</quote> command also allows " "<literal>pre:</literal> dependencies, or a mixture of both " "<literal>pre:</literal> and <literal>post:</literal> dependencies. See the " "<filename>modprobe.d(5)</filename> manual page for more information on " "<quote>softdep</quote> syntax and capabilities." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:230 msgid "" "If the module in question is not a wrapper and is useful by itself, " "configure the <command>modules</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." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:239 msgid "Udev loads some unwanted module" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:241 msgid "" "Either don't build the module, or blacklist it in a " "<filename>/etc/modprobe.d/blacklist.conf</filename> file as done with the " "<emphasis>forte</emphasis> module in the example below:" msgstr "" #. type: Content of: <sect1><sect2><sect3><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:245 #, no-wrap msgid "<literal>blacklist forte</literal>" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:247 msgid "" "Blacklisted modules can still be loaded manually with the explicit " "<command>modprobe</command> command." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:253 msgid "Udev creates a device incorrectly, or makes a wrong symlink" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:255 msgid "" "This usually happens if a rule unexpectedly matches a device. For example, a " "poorly-written rule can match both a SCSI disk (as desired) and the " "corresponding SCSI generic device (incorrectly) by vendor. Find the " "offending rule and make it more specific, with the help of the " "<command>udevadm info</command> command." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:264 msgid "Udev rule works unreliably" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:266 msgid "" "This may be another manifestation of the previous problem. If not, and your " "rule uses <systemitem class=\"filesystem\">sysfs</systemitem> attributes, it " "may be a kernel timing issue, to be fixed in later kernels. For now, you " "can work around it by creating a rule that waits for the used <systemitem " "class=\"filesystem\">sysfs</systemitem> attribute and appending it to the " "<filename>/etc/udev/rules.d/10-wait_for_sysfs.rules</filename> file (create " "this file if it does not exist). Please notify the LFS Development list if " "you do so and it helps." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:278 msgid "Udev does not create a device" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:280 msgid "" "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." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:284 msgid "" "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 <command>udev</command>." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:298 msgid "Device naming order changes randomly after rebooting" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:300 msgid "" "This is due to the fact that udev, by design, handles uevents and loads " "modules in parallel, and thus in an unpredictable order. This will never be " "<quote>fixed</quote>. You should not rely upon the kernel device names being " "stable. Instead, create your own rules that make symlinks with stable names " "based on some stable attributes of the device, such as a serial number or " "the output of various *_id utilities installed by udev. See <xref " "linkend=\"ch-config-symlinks\"/> and <xref linkend=\"ch-config-network\"/> " "for examples." msgstr "" #. type: Content of: <sect1><sect2><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:314 msgid "Useful Reading" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:316 msgid "Additional helpful documentation is available at the following sites:" msgstr "" #. type: Content of: <sect1><sect2><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:322 msgid "" "A Userspace Implementation of <systemitem " "class=\"filesystem\">devfs</systemitem> <ulink " "url=\"http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf\"/>" msgstr "" #. type: Content of: <sect1><sect2><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:327 msgid "" "The <systemitem class=\"filesystem\">sysfs</systemitem> Filesystem <ulink " "url=\"http://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/mochel.pdf\"/>" msgstr ""

# SOME DESCRIPTIVE TITLE # Copyright (C) YEAR Free Software Foundation, Inc. # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "POT-Creation-Date: 2020-06-17 12:44+0800\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "Language: \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. type: Content of: #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:11 msgid "Overview of Device and Module Handling" msgstr "" #. type: Content of: <sect1><indexterm><primary> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:14 msgid "Udev" msgstr "" #. type: Content of: <sect1><indexterm><secondary> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:15 msgid "usage" msgstr "" #. type: Content of: <sect1><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:18 msgid "" "In <xref linkend=\"chapter-building-system\"/>, we installed the udev " "package when <phrase revision=\"sysv\">eudev</phrase> <phrase " "revision=\"systemd\">systemd</phrase> was built. Before we go into the " "details regarding how this works, a brief history of previous methods of " "handling devices is in order." msgstr "" #. type: Content of: <sect1><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:24 msgid "" "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 " "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." msgstr "" #. type: Content of: <sect1><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:33 msgid "" "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\">devtmpfs</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." msgstr "" #. type: Content of: <sect1><sect2><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:41 msgid "History" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:43 msgid "" "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." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:50 msgid "" "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 as deprecated for a long " "period – due to a lack of maintenance – and was finally removed " "from the kernel in June, 2006." msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:63 msgid "" "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 developing a userspace replacement for " "<systemitem class=\"filesystem\">devfs</systemitem> became much more " "realistic." msgstr "" #. type: Content of: <sect1><sect2><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:75 msgid "Udev Implementation" msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:78 msgid "Sysfs" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:80 msgid "" "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 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)." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:97 msgid "Device Node Creation" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:99 msgid "" "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 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 " "will initially be created with a fixed name, permissions, and owner." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:108 msgid "" "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 (name) for that object." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:117 msgid "" "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." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:124 msgid "Module Loading" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:126 msgid "" "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 with 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 (which 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." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:145 msgid "" "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." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:151 msgid "" "The kernel itself is also able to load modules for network protocols, " "filesystems, and NLS support on demand." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:157 msgid "Handling Hotpluggable/Dynamic Devices" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:159 msgid "" "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." msgstr "" #. type: Content of: <sect1><sect2><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:169 msgid "Problems with Loading Modules and Creating Devices" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:171 msgid "" "There are a few possible problems when it comes to automatically creating " "device nodes." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:175 msgid "A kernel module is not loaded automatically" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:177 msgid "" "Udev will only load a module if it has a bus-specific alias and the bus " "driver properly exports the necessary aliases to <systemitem " "class=\"filesystem\">sysfs</systemitem>. In other cases, one should arrange " "module loading by other means. With Linux-&linux-version;, udev is known to " "load properly-written drivers for INPUT, IDE, PCI, USB, SCSI, SERIO, and " "FireWire devices." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:184 msgid "" "To determine if the device driver you require has the necessary support for " "udev, run <command>modinfo</command> with the module name as the argument. " "Now try locating the device directory under <filename " "class=\"directory\">/sys/bus</filename> and check whether there is a " "<filename>modalias</filename> file there." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:190 msgid "" "If the <filename>modalias</filename> file exists in <systemitem " "class=\"filesystem\">sysfs</systemitem>, the driver supports the device and " "can talk to it directly, but doesn't have the alias, it is a bug in the " "driver. Load the driver without the help from udev and expect the issue to " "be fixed later." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:196 msgid "" "If there is no <filename>modalias</filename> file in the relevant directory " "under <filename class=\"directory\">/sys/bus</filename>, this means that the " "kernel developers have not yet added modalias support to this bus type. With " "Linux-&linux-version;, this is the case with ISA busses. Expect this issue " "to be fixed in later kernel versions." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:202 msgid "" "Udev is not intended to load <quote>wrapper</quote> drivers such as " "<emphasis>snd-pcm-oss</emphasis> and non-hardware drivers such as " "<emphasis>loop</emphasis> at all." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:209 msgid "" "A kernel module is not loaded automatically, and udev is not intended to " "load it" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:212 msgid "" "If the <quote>wrapper</quote> module only enhances the functionality " "provided by some other module (e.g., <emphasis>snd-pcm-oss</emphasis> " "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 a <quote>softdep</quote> line to the corresponding " "<filename>/etc/modprobe.d/<replaceable><filename></replaceable>.conf</filename> " "file. For example:" msgstr "" #. type: Content of: <sect1><sect2><sect3><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:222 #, no-wrap msgid "<literal>softdep snd-pcm post: snd-pcm-oss</literal>" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:224 msgid "" "Note that the <quote>softdep</quote> command also allows " "<literal>pre:</literal> dependencies, or a mixture of both " "<literal>pre:</literal> and <literal>post:</literal> dependencies. See the " "<filename>modprobe.d(5)</filename> manual page for more information on " "<quote>softdep</quote> syntax and capabilities." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:230 msgid "" "If the module in question is not a wrapper and is useful by itself, " "configure the <command>modules</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." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:239 msgid "Udev loads some unwanted module" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:241 msgid "" "Either don't build the module, or blacklist it in a " "<filename>/etc/modprobe.d/blacklist.conf</filename> file as done with the " "<emphasis>forte</emphasis> module in the example below:" msgstr "" #. type: Content of: <sect1><sect2><sect3><screen> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:245 #, no-wrap msgid "<literal>blacklist forte</literal>" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:247 msgid "" "Blacklisted modules can still be loaded manually with the explicit " "<command>modprobe</command> command." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:253 msgid "Udev creates a device incorrectly, or makes a wrong symlink" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:255 msgid "" "This usually happens if a rule unexpectedly matches a device. For example, a " "poorly-written rule can match both a SCSI disk (as desired) and the " "corresponding SCSI generic device (incorrectly) by vendor. Find the " "offending rule and make it more specific, with the help of the " "<command>udevadm info</command> command." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:264 msgid "Udev rule works unreliably" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:266 msgid "" "This may be another manifestation of the previous problem. If not, and your " "rule uses <systemitem class=\"filesystem\">sysfs</systemitem> attributes, it " "may be a kernel timing issue, to be fixed in later kernels. For now, you " "can work around it by creating a rule that waits for the used <systemitem " "class=\"filesystem\">sysfs</systemitem> attribute and appending it to the " "<filename>/etc/udev/rules.d/10-wait_for_sysfs.rules</filename> file (create " "this file if it does not exist). Please notify the LFS Development list if " "you do so and it helps." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:278 msgid "Udev does not create a device" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:280 msgid "" "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." msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:284 msgid "" "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 <command>udev</command>." msgstr "" #. type: Content of: <sect1><sect2><sect3><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:298 msgid "Device naming order changes randomly after rebooting" msgstr "" #. type: Content of: <sect1><sect2><sect3><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:300 msgid "" "This is due to the fact that udev, by design, handles uevents and loads " "modules in parallel, and thus in an unpredictable order. This will never be " "<quote>fixed</quote>. You should not rely upon the kernel device names being " "stable. Instead, create your own rules that make symlinks with stable names " "based on some stable attributes of the device, such as a serial number or " "the output of various *_id utilities installed by udev. See <xref " "linkend=\"ch-config-symlinks\"/> and <xref linkend=\"ch-config-network\"/> " "for examples." msgstr "" #. type: Content of: <sect1><sect2><title> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:314 msgid "Useful Reading" msgstr "" #. type: Content of: <sect1><sect2><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:316 msgid "Additional helpful documentation is available at the following sites:" msgstr "" #. type: Content of: <sect1><sect2><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:322 msgid "" "A Userspace Implementation of <systemitem " "class=\"filesystem\">devfs</systemitem> <ulink " "url=\"http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf\"/>" msgstr "" #. type: Content of: <sect1><sect2><itemizedlist><listitem><para> #: /home/xry111/svn-repos/LFS-BOOK/chapter09/udev.xml:327 msgid "" "The <systemitem class=\"filesystem\">sysfs</systemitem> Filesystem <ulink " "url=\"http://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/mochel.pdf\"/>" msgstr ""