|
@@ -0,0 +1,519 @@
|
|
|
|
+<?xml version="1.0" encoding="UTF-8"?>
|
|
|
|
+<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|
|
|
+ "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
|
|
|
+ <!ENTITY % general-entities SYSTEM "../general.ent">
|
|
|
|
+ %general-entities;
|
|
|
|
+]>
|
|
|
|
+
|
|
|
|
+<sect1 id="ch-scripts-udev">
|
|
|
|
+ <?dbhtml filename="udev.html"?>
|
|
|
|
+
|
|
|
|
+ <title>设备和模块管理概述</title>
|
|
|
|
+
|
|
|
|
+ <indexterm zone="ch-scripts-udev">
|
|
|
|
+ <primary sortas="a-Udev">Udev</primary>
|
|
|
|
+ <secondary>usage</secondary>
|
|
|
|
+ </indexterm>
|
|
|
|
+
|
|
|
|
+ <!--para>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.</para-->
|
|
|
|
+ <para>在 <xref linkend="chapter-building-system"/> 中,我们在构建
|
|
|
|
+ <phrase revision="sysv">eudev</phrase>
|
|
|
|
+ <phrase revision="systemd">systemd</phrase>
|
|
|
|
+ 时安装了 Udev 软件包。在我们详细讨论它的工作原理之前,
|
|
|
|
+ 首先按时间顺序简要介绍历史上曾经使用过的设备管理方式。</para>
|
|
|
|
+
|
|
|
|
+ <!--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 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-->
|
|
|
|
+ <para>传统的 Linux 系统通常使用静态设备创建方法,即在
|
|
|
|
+ <filename class="directory">/dev</filename> 下创建大量设备节点
|
|
|
|
+ (有时有数千个节点),无论对应的硬件设备是否真的存在。
|
|
|
|
+ 一般通过 <command>MAKEDEV</command> 脚本完成这一工作,
|
|
|
|
+ 它包含以相关的主设备号和次设备号,
|
|
|
|
+ 为世界上可能存在的每个设备建立节点的大量 <command>mknod</command>
|
|
|
|
+ 程序调用。</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">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.</para-->
|
|
|
|
+ <para>使用 Udev 方法,
|
|
|
|
+ 只有那些被内核检测到的设备才会获得为它们创建的设备节点。
|
|
|
|
+ 由于这些设备节点在每次引导系统时都会重新创建,
|
|
|
|
+ 它们被储存在 <systemitem class="filesystem">devtmpfs</systemitem>
|
|
|
|
+ 文件系统中(一个虚拟文件系统,完全驻留在系统内存)。
|
|
|
|
+ 设备节点不需要太多空间,它们使用的系统内存可以忽略不计。</para>
|
|
|
|
+
|
|
|
|
+ <sect2>
|
|
|
|
+ <title>历史</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>在 2000 年 2 月,一个称为 <systemitem class="filesystem">devfs
|
|
|
|
+ </systemitem> 的新文件系统被合并到 2.3.46 版内核中,
|
|
|
|
+ 并在 2.4 系列稳定内核中可用。尽管它本身曾经存在于内核源代码中,
|
|
|
|
+ 但这种设备节点动态创建方法从未得到内核核心开发者的大力支持。
|
|
|
|
+ </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 as deprecated for a long
|
|
|
|
+ period – due to a lack of maintenance – and was finally removed
|
|
|
|
+ from the kernel in June, 2006.</para-->
|
|
|
|
+ <para><systemitem class="filesystem">devfs</systemitem>
|
|
|
|
+ 采用的这种方法的主要问题是它处理设备的检测、创建和命名的方式,
|
|
|
|
+ 其中最致命的是设备节点命名方式。一个被广泛接受的理念是,
|
|
|
|
+ 如果设备名称是允许配置的,那么设备命名策略应该由系统管理员,
|
|
|
|
+ 而不是某个(些)特定开发者决定。
|
|
|
|
+ <systemitem class="filesystem">devfs</systemitem>
|
|
|
|
+ 还受到其设计中固有的竞争条件的严重影响,
|
|
|
|
+ 在不对内核进行大量修改的前提下无法修复这一问题。
|
|
|
|
+ 在一段时间后,由于缺乏维护,它被标记为过时特性,最终在
|
|
|
|
+ 2006 年 6 月被从内核中移除。</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 developing a userspace
|
|
|
|
+ replacement for <systemitem class="filesystem">devfs</systemitem> became
|
|
|
|
+ much more realistic.</para-->
|
|
|
|
+ <para>在不稳定的 2.5 系列内核开发过程中,加入了一个新的虚拟文件系统,
|
|
|
|
+ 称为 <systemitem class="filesystem">sysfs</systemitem> ,
|
|
|
|
+ 并在 2.6 系列稳定内核中发布。
|
|
|
|
+ 它的工作是将系统硬件配置信息导出给用户空间进程,
|
|
|
|
+ 有了这个用户空间可见的配置描述,就可能开发一种
|
|
|
|
+ <systemitem class="filesystem">devfs</systemitem>
|
|
|
|
+ 的用户空间替代品。</para>
|
|
|
|
+
|
|
|
|
+ </sect2>
|
|
|
|
+
|
|
|
|
+ <sect2>
|
|
|
|
+ <title>Udev 实现</title>
|
|
|
|
+
|
|
|
|
+ <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
|
|
|
|
+ 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-->
|
|
|
|
+ <para>前面已经简要提到了
|
|
|
|
+ <systemitem class="filesystem">sysfs</systemitem> 文件系统。
|
|
|
|
+ 有些读者可能好奇,
|
|
|
|
+ <systemitem class="filesystem">sysfs</systemitem>
|
|
|
|
+ 是如何知道系统中存在哪些设备,以及应该为它们使用什么设备号的。
|
|
|
|
+ 答案是,那些编译到内核中的驱动程序在它们的对象被内核检测到时,
|
|
|
|
+ 直接将它们注册到 <systemitem class="filesystem">sysfs</systemitem>
|
|
|
|
+ (内部的 devtmpfs)。对于那些被编译为模块的驱动程序,
|
|
|
|
+ 注册过程在模块加载时进行。只要
|
|
|
|
+ <systemitem class="filesystem">sysfs</systemitem>
|
|
|
|
+ 文件系统被挂载好(位于 /sys),用户空间程序即可使用驱动程序注册在
|
|
|
|
+ <systemitem class="filesystem">sysfs</systemitem>
|
|
|
|
+ 中的数据,Udev 就能够使用这些数据对设备进行处理
|
|
|
|
+ (包括修改设备节点)。</para>
|
|
|
|
+ </sect3>
|
|
|
|
+
|
|
|
|
+ <sect3>
|
|
|
|
+ <title>设备节点的创建</title>
|
|
|
|
+
|
|
|
|
+ <!--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 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.</para-->
|
|
|
|
+ <para>内核通过 <systemitem class="filesystem">devtmpfs</systemitem>
|
|
|
|
+ 直接创建设备文件,任何希望注册设备节点的驱动程序都要通过
|
|
|
|
+ <systemitem class="filesystem">devtmpfs</systemitem>
|
|
|
|
+ (经过驱动程序核心)实现。当一个
|
|
|
|
+ <systemitem class="filesystem">devtmpfs</systemitem>
|
|
|
|
+ 实例被挂载到 <filename class="directory">/dev</filename>
|
|
|
|
+ 时,设备节点将被以固定的名称、访问权限和所有者首次创建。</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 (name) for that object.</para-->
|
|
|
|
+ <para>很快,内核会向 <command>udevd</command> 发送一个 uevent 事件。
|
|
|
|
+ 根据 <filename class="directory">/etc/udev/rules.d</filename>、
|
|
|
|
+ <filename class="directory">/lib/udev/rules.d</filename>
|
|
|
|
+ 以及 <filename class="directory">/run/udev/rules.d</filename>
|
|
|
|
+ 中的规则,<command>udevd</command>
|
|
|
|
+ 将为设备节点创建额外的符号链接,或修改其访问权限、所有者、属组,
|
|
|
|
+ 或修改该对象的 <command>udevd</command> 数据库条目(名称)。
|
|
|
|
+ </para>
|
|
|
|
+
|
|
|
|
+ <!--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-->
|
|
|
|
+ <para>以上三个目录中的规则都被编号,且这三个目录的内容将合并处理。
|
|
|
|
+ 如果 <command>udevd</command> 找不到它正在创建的设备对应的规则,
|
|
|
|
+ 它将会沿用 <systemitem class="filesystem">devtmpfs</systemitem>
|
|
|
|
+ 最早使用的访问权限和所有权。</para>
|
|
|
|
+ </sect3>
|
|
|
|
+
|
|
|
|
+ <sect3 id="ch-module-loading">
|
|
|
|
+ <title>模块加载</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 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.</para-->
|
|
|
|
+ <para>编译为内核模块的设备驱动程序可能有内建的别名,
|
|
|
|
+ 别名可以通过 <command>modinfo</command> 程序查询,
|
|
|
|
+ 它通常和该模块支持的设备的总线相关标识符有关。
|
|
|
|
+ 例如,<emphasis>snd-fm801</emphasis> 驱动程序支持厂商 ID 为
|
|
|
|
+ 0x1319,设备 ID 为 0x0801 的 PCI 设备,其别名为
|
|
|
|
+ <quote>pci:v00001319d00000801sv*sd*bc04sc01l*</quote>。
|
|
|
|
+ 对于多数设备,总线驱动程序会通过
|
|
|
|
+ <systemitem class="filesystem">sysfs</systemitem>
|
|
|
|
+ 导出应该处理该设备的驱动程序别名,例如
|
|
|
|
+ <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename>
|
|
|
|
+ 文件应该包含字符串
|
|
|
|
+ <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00
|
|
|
|
+ </quote>。Udev 附带的默认规则会导致 <command>udevd</command>
|
|
|
|
+ 以 <envar>MODALIAS</envar> uevent 环境变量的内容
|
|
|
|
+ (应该和 sysfs 的 <filename>modalias</filename> 文件内容一致)调用
|
|
|
|
+ <command>/sbin/modprobe</command>,并加载在通配符扩展后,
|
|
|
|
+ 别名能够匹配该字符串的所有模块。</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>在本例中,这意味着除了 <emphasis>snd-fm801</emphasis>
|
|
|
|
+ 外,过时(且不希望)的 <emphasis>forte</emphasis> 如果可用,
|
|
|
|
+ 也会被加载。下面将介绍防止加载不希望的驱动程序的方法。</para>
|
|
|
|
+
|
|
|
|
+ <!--para>The kernel itself is also able to load modules for network
|
|
|
|
+ protocols, filesystems and NLS support on demand.</para-->
|
|
|
|
+ <para>内核本身也能够在需要时为网络协议、文件系统和 NLS
|
|
|
|
+ 支持加载模块。</para>
|
|
|
|
+
|
|
|
|
+ </sect3>
|
|
|
|
+
|
|
|
|
+ <sect3 id="ch-hotplug-device">
|
|
|
|
+ <title>处理热插拔/动态设备</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-->
|
|
|
|
+ <para>当您插入一个设备,例如通用串行总线(USB) MP3 播放器时,
|
|
|
|
+ 内核能够发现该设备现在已经被连接到系统,并生成一个 uevent 事件。
|
|
|
|
+ 之后 <command>udevd</command> 像前面描述的一样,处理该
|
|
|
|
+ uevent 事件。</para>
|
|
|
|
+
|
|
|
|
+ </sect3>
|
|
|
|
+
|
|
|
|
+ </sect2>
|
|
|
|
+
|
|
|
|
+ <sect2>
|
|
|
|
+ <title>加载模块和创建设备时的问题</title>
|
|
|
|
+
|
|
|
|
+ <para>在自动创建设备节点时,可能发现一些问题。</para>
|
|
|
|
+
|
|
|
|
+ <sect3>
|
|
|
|
+ <title>内核模块没有自动加载</title>
|
|
|
|
+
|
|
|
|
+ <!--para>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.</para-->
|
|
|
|
+ <para>Udev 只加载拥有总线特定别名,且总线驱动程序正确地向
|
|
|
|
+ <systemitem class="filesystem">sysfs</systemitem>
|
|
|
|
+ 导出了必要别名的模块。如果情况不是这样,
|
|
|
|
+ 您应该考虑用其他方法加载模块。在 Linux-&linux-version; 中,
|
|
|
|
+ 已知 Udev 可以加载编写正确的 INPUT、IDE、PCI、USB、SCSI、SERIO
|
|
|
|
+ 和 FireWire 驱动程序。</para>
|
|
|
|
+
|
|
|
|
+ <!--para>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.</para-->
|
|
|
|
+ <para>为了确定您需要的设备驱动程序是否包含 Udev 支持,
|
|
|
|
+ 以模块名为参数运行 <command>modinfo</command> 命令。
|
|
|
|
+ 然后试着在 <filename class="directory">/sys/bus</filename>
|
|
|
|
+ 中找到设备对应的目录,并检查其中是否有
|
|
|
|
+ <filename>modalias</filename> 文件。</para>
|
|
|
|
+
|
|
|
|
+ <!--para>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.</para-->
|
|
|
|
+ <para>如果 <systemitem class="filesystem">sysfs</systemitem> 中有
|
|
|
|
+ <filename>modalias</filename> 文件,说明驱动程序支持该设备,
|
|
|
|
+ 并能够直接和设备交互,但却没有正确地别名。这是驱动程序的 bug ,
|
|
|
|
+ 您需要不通过 Udev 直接加载驱动,并等待这个问题日后被解决。</para>
|
|
|
|
+
|
|
|
|
+ <!--para>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.</para-->
|
|
|
|
+ <para>如果在 <filename class="directory">/sys/bus</filename>
|
|
|
|
+ 下的相关目录中没有 <filename>modalias</filename> 文件,
|
|
|
|
+ 说明内核开发者尚未对该总线类型增加 modalias 支持。
|
|
|
|
+ 在 Linux-&linux-version; 中,ISA 总线不受支持。
|
|
|
|
+ 只能等待这个问题在日后被解决。</para>
|
|
|
|
+
|
|
|
|
+ <!--para>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.</para-->
|
|
|
|
+ <para>Udev 根本不会尝试加载 <emphasis>snd-pcm-oss</emphasis>
|
|
|
|
+ 等 <quote>包装器</quote> 驱动程序,或 <emphasis>loop</emphasis>
|
|
|
|
+ 等非硬件驱动程序。</para>
|
|
|
|
+
|
|
|
|
+ </sect3>
|
|
|
|
+
|
|
|
|
+ <sect3>
|
|
|
|
+ <title>内核模块没有自动加载,且 Udev 不尝试加载它</title>
|
|
|
|
+
|
|
|
|
+ <!--para>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:</para-->
|
|
|
|
+ <para>如果 <quote>包装器</quote> 仅仅用于增强其他模块的功能
|
|
|
|
+ (例如,<emphasis>snd-pcm-oss</emphasis> 增强
|
|
|
|
+ <emphasis>snd-pcm</emphasis> 的功能,
|
|
|
|
+ 使 OSS 应用程序能够使用声卡),需要配置
|
|
|
|
+ <command>modprobe</command> 使其在 Udev 加载被包装的模块时,
|
|
|
|
+ 自动加载包装器。为此,在对应的
|
|
|
|
+<filename>/etc/modprobe.d/<replaceable><filename></replaceable>.conf
|
|
|
|
+ </filename> 文件中加入一个
|
|
|
|
+ <quote>softdep</quote> 行,例如:</para>
|
|
|
|
+
|
|
|
|
+<screen role="nodump"><literal>softdep snd-pcm post: snd-pcm-oss</literal></screen>
|
|
|
|
+
|
|
|
|
+ <!--para>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>. See the
|
|
|
|
+ <filename>modprobe.d(5)</filename> manual page for more information
|
|
|
|
+ on <quote>softdep</quote> syntax and capabilities.</para-->
|
|
|
|
+ <para>注意 <quote>softdep</quote> 命令也允许 <literal>pre:</literal>
|
|
|
|
+ 依赖项,或混合使用 <literal>pre:</literal> 和
|
|
|
|
+ <literal>post:</literal> 依赖项。参阅
|
|
|
|
+ <filename>modprobe.d(5)</filename> man 手册页面,
|
|
|
|
+ 了解更多关于 <quote>softdep</quote> 语法和功能的信息。</para>
|
|
|
|
+
|
|
|
|
+ <!--para>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.</para-->
|
|
|
|
+ <para>如果出现问题的模块不是包装器,而是本身就有特定功能的模块,
|
|
|
|
+ 需要配置 <command>modules</command> 启动脚本以在系统引导时加载它。
|
|
|
|
+ 为此,将模块名添加到 <filename>/etc/sysconfig/modules</filename>
|
|
|
|
+ 中,作为单独的一行。包装器模块也可以被添加到这里,
|
|
|
|
+ 但对于包装器来说这不是最好的方案。</para>
|
|
|
|
+
|
|
|
|
+ </sect3>
|
|
|
|
+
|
|
|
|
+ <sect3>
|
|
|
|
+ <title>Udev 加载了不希望的模块</title>
|
|
|
|
+
|
|
|
|
+ <!--para>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:</para-->
|
|
|
|
+ <para>不要构建该模块,或者在
|
|
|
|
+ <filename>/etc/modprobe.d/blacklist.conf</filename>
|
|
|
|
+ 文件中禁用它。以 <emphasis>forte</emphasis> 为例,
|
|
|
|
+ 下面一行禁用了该模块:</para>
|
|
|
|
+
|
|
|
|
+<screen role="nodump"><literal>blacklist forte</literal></screen>
|
|
|
|
+
|
|
|
|
+ <!--para>Blacklisted modules can still be loaded manually with the
|
|
|
|
+ explicit <command>modprobe</command> command.</para-->
|
|
|
|
+ <para>被禁用的模块仍然可以通过直接执行 <command>modprobe</command>
|
|
|
|
+ 手动加载。</para>
|
|
|
|
+
|
|
|
|
+ </sect3>
|
|
|
|
+
|
|
|
|
+ <sect3>
|
|
|
|
+ <title>Udev 创建了错误的设备或错误的符号链接</title>
|
|
|
|
+
|
|
|
|
+ <!--para>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.</para-->
|
|
|
|
+ <para>这一般是由于一条规则意外地匹配了某个设备。
|
|
|
|
+ 例如,一个写得不好的规则可能同时匹配到 SCSI 磁盘(正确的)
|
|
|
|
+ 和对应厂商的 SCSI 通用设备(不正确的)。
|
|
|
|
+ 找到引起问题的规则,并通过 <command>udevadm info</command>
|
|
|
|
+ 的帮助,将它进一步细化。</para>
|
|
|
|
+
|
|
|
|
+ </sect3>
|
|
|
|
+
|
|
|
|
+ <sect3>
|
|
|
|
+ <title>Udev 规则工作不可靠</title>
|
|
|
|
+
|
|
|
|
+ <!--para>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.</para-->
|
|
|
|
+ <para>这可能是前一个问题的另一个表现形式。如果不是,
|
|
|
|
+ 而且您的规则使用了
|
|
|
|
+ <systemitem class="filesystem">sysfs</systemitem> 属性,
|
|
|
|
+ 这个问题可能由内核计时问题引发,这类问题需要在新的内核版本中修复。
|
|
|
|
+ 目前,您可以创建一条规则以等待被使用的
|
|
|
|
+ <systemitem class="filesystem">sysfs</systemitem> 属性,
|
|
|
|
+ 并将它附加到 <filename>/etc/udev/rules.d/10-wait-for-sysfs.rules
|
|
|
|
+ </filename> 文件中(如果不存在就创建一个文件),绕过这个问题。
|
|
|
|
+ 如果您通过这种方法解决了问题,请通知 LFS 开发邮件列表。</para>
|
|
|
|
+
|
|
|
|
+ </sect3>
|
|
|
|
+
|
|
|
|
+ <sect3>
|
|
|
|
+ <title>Udev 没有创建设备</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 没有创建命名错误的设备。</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 <command>udev</command>.</para-->
|
|
|
|
+ <para>如果驱动程序没有将它的信息导出到
|
|
|
|
+ <systemitem class="filesystem">sysfs</systemitem>,
|
|
|
|
+ Udev 就无法获得创建设备节点必需的信息。
|
|
|
|
+ 这种问题往往出现在内核源代码树以外的第三方驱动程序中。
|
|
|
|
+ 这时,需要在 <filename>/lib/udev/devices</filename>
|
|
|
|
+ 中使用正确的主设备号和次设备号,创建一个静态设备节点
|
|
|
|
+ (参考内核文档中的 <filename>devices.txt</filename>
|
|
|
|
+ 或第三方驱动厂商提供的文档),<command>udev</command>
|
|
|
|
+ 会将该静态设备节点复制到 <filename class="directory">/dev
|
|
|
|
+ </filename>。</para>
|
|
|
|
+
|
|
|
|
+ </sect3>
|
|
|
|
+
|
|
|
|
+ <sect3>
|
|
|
|
+ <title>重启后设备命名顺序随机变化</title>
|
|
|
|
+
|
|
|
|
+ <!--para>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-scripts-symlinks"/> and
|
|
|
|
+ <xref linkend="ch-scripts-network"/> for examples.</para-->
|
|
|
|
+ <para>这是由于 Udev 从设计上就是并行加载模块的,因此无法预测加载顺序。
|
|
|
|
+ 这个问题永远也不会被 <quote>修复</quote>。
|
|
|
|
+ 您不应该指望内核提供稳定的设备命名,而是应该创建您自己的规则,
|
|
|
|
+ 以根据设备的一些稳定属性,例如设备序列号或 Udev 安装的一些
|
|
|
|
+ *_id 工具的输出,来创建具有稳定名称的符号链接。
|
|
|
|
+ 可以参考 <xref linkend="ch-scripts-symlinks"/> 和
|
|
|
|
+ <xref linkend="ch-scripts-network"/> 中的例子。</para>
|
|
|
|
+
|
|
|
|
+ </sect3>
|
|
|
|
+
|
|
|
|
+ </sect2>
|
|
|
|
+
|
|
|
|
+ <sect2>
|
|
|
|
+ <title>扩展阅读</title>
|
|
|
|
+
|
|
|
|
+ <para>以下链接包含了一些额外的帮助文档:</para>
|
|
|
|
+
|
|
|
|
+ <itemizedlist>
|
|
|
|
+
|
|
|
|
+ <listitem>
|
|
|
|
+ <para>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"/></para>
|
|
|
|
+ </listitem>
|
|
|
|
+
|
|
|
|
+ <listitem>
|
|
|
|
+ <para>The <systemitem class="filesystem">sysfs</systemitem> Filesystem
|
|
|
|
+ <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>
|
|
|
|
+
|
|
|
|
+</sect1>
|