9.3. 设备和模块管理概述

9.3.2.1. Sysfs

前面已经简要提到了 sysfs 文件系统。有些读者可能好奇，sysfs 是如何知道系统中存在哪些设备，以及应该为它们使用什么设备号的。答案是，那些编译到内核中的驱动程序在对应设备被内核检测到时，直接将它们注册到 sysfs (内部的 devtmpfs)。对于那些被编译为模块的驱动程序，注册过程在模块加载时进行。只要 sysfs 文件系统被挂载好 (位于 /sys)，用户空间程序即可使用驱动程序注册在 sysfs 中的数据，udev 就能够使用这些数据对设备进行处理 (包括修改设备节点)。

9.3.2.2. 设备节点的创建

内核通过 devtmpfs 直接创建设备文件，任何希望注册设备节点的驱动程序都要通过 devtmpfs (经过驱动程序核心) 进行注册。当一个 devtmpfs 实例被挂载到 /dev 时，设备节点将被以固定的名称、访问权限和所有者首次创建。

很快，内核会向 udevd 发送一个 uevent。根据 /etc/udev/rules.d，/usr/lib/udev/rules.d，以及 /run/udev/rules.d 目录中文件指定的规则，udevd 将为设备节点创建额外的符号链接，修改其访问权限，所有者，或属组，或者修改该对象的 udevd 数据库条目 (名称)。

以上三个目录中的规则都被编号，且这三个目录的内容将合并处理。如果 udevd 找不到它正在创建的设备对应的规则，它将会沿用 devtmpfs 最早使用的配置。

9.3.2.3. 模块加载

编译为内核模块的设备驱动程序可能有内建的别名。别名可以通过 modinfo 程序查询，它通常和该模块支持的设备的总线相关标识符有关。例如，snd-fm801 驱动程序支持厂商 ID 为 0x1319，设备 ID 为 0x0801 的 PCI 设备，其别名为 pci:v00001319d00000801sv*sd*bc04sc01l*。对于多数设备，总线驱动程序会通过 sysfs 导出应该处理该设备的驱动程序别名，例如 /sys/bus/pci/devices/0000:00:0d.0/modalias 文件应该包含字符串 pci:v00001319d00000801sv00001319sd00001319bc04sc01i00。Udev 附带的默认规则会导致 udevd 调用 /sbin/modprobe 时传递 MODALIAS uevent 环境变量 (它的值应该和 sysfs 中 modalias 文件的内容相同)，从而加载那些在通配符扩展后别名与这个字符串匹配的模块。

在本例中，这意味着除了 snd-fm801 外，过时 (且不希望) 的 forte 如果可用，也会被加载。之后将介绍防止加载不希望的驱动程序的方法。

内核本身也能够在需要时为网络协议，文件系统，以及 NLS 支持加载模块。

9.3.2.4. 处理热插拔/动态设备

当您插入一个设备，例如通用串行总线 (USB) MP3 播放器时，内核能够发现该设备现在已经被连接到系统，并生成一个 uevent 事件。之后 udevd 像前面描述的一样，处理该 uevent 事件。

9.3.3.1. 内核模块没有自动加载

Udev 只加载拥有总线特定别名，且总线驱动程序正确地向 sysfs 导出了必要别名的模块。如果情况不是这样，您应该考虑用其他方法加载模块。在 Linux-6.12.5 中，已知 Udev 可以加载编写正确的 INPUT，IDE，PCI，USB，SCSI，SERIO，以及 FireWire 驱动程序。

为了确定您需要的设备驱动程序是否包含 Udev 支持，以模块名为参数运行 modinfo 命令。然后试着在 /sys/bus 中找到设备对应的目录，并检查其中是否有 modalias 文件。

如果 modalias 文件存在于 sysfs 中，说明驱动程序支持该设备，并能够直接和设备交互，但却没有正确的别名。这是驱动程序的 bug，您需要不通过 Udev 直接加载驱动，并等待这个问题日后被解决。

如果 modalias 文件不存在于 /sys/bus 下的对应目录中，说明内核开发者尚未对该总线类型增加 modalias 支持。在 Linux-6.12.5 中，ISA 总线不受支持。只能等待这个问题在日后被解决。

Udev 根本不会尝试加载“包装器” 驱动程序，比如 snd-pcm-oss 等，或 loop 等非硬件驱动程序。

9.3.3.2. 内核模块没有自动加载，且 Udev 不尝试加载它

如果“包装器”仅仅用于增强其他模块的功能 (例如，snd-pcm-oss 增强 snd-pcm 的功能，使 OSS 应用程序能够使用声卡)，需要配置 modprobe，使其在 Udev 加载被包装的模块时，自动加载包装器。为此，需要将“softdep”行添加到对应的 /etc/modprobe.d/<filename>.conf 中。例如：

softdep snd-pcm post: snd-pcm-oss

注意“softdep”命令也允许 pre: 依赖项，或混合使用 pre: 和 post: 依赖项。参阅 modprobe.d(5) 手册页，了解更多关于“softdep”语法和功能的信息。

如果出现问题的模块不是包装器，而是本身就有特定功能的模块，需要配置 modules 引导脚本以在系统引导时加载它。为此，将模块名添加到 /etc/sysconfig/modules 中，作为单独的一行。包装器模块也可以被添加到这里，但对于包装器来说这不是最好的方案。

9.3.3.3. Udev 加载了不希望的模块

不要构建该模块，或者在 /etc/modprobe.d/blacklist.conf 文件中禁用它。以 forte 为例，下面一行禁用了该模块：

blacklist forte

被禁用的模块仍然可以通过直接执行 modprobe 手动加载。

9.3.3.4. Udev 创建了错误的设备或错误的符号链接

这一般是由于一条规则意外地匹配了某个设备。例如，一个写得不好的规则可能同时匹配到 SCSI 磁盘 (正确的) 和对应厂商的 SCSI 通用设备 (不正确的)。找到引起问题的规则，并通过 udevadm info 的帮助，将它进一步细化。

9.3.3.5. Udev 规则工作不可靠

这可能是前一个问题的另一个表现形式。如果不是，而且您的规则使用了 sysfs 属性，这个问题可能由内核计时问题引发，这类问题需要在新的内核版本中修复。目前，您可以创建一条规则以等待被使用的 sysfs 属性，并将它附加到 /etc/udev/rules.d/10-wait-for-sysfs.rules 文件中 (如果不存在就创建一个文件)，绕过这个问题。如果您通过这种方法解决了问题，请通知 LFS 开发邮件列表。

9.3.3.6. Udev 没有创建设备

首先，确认驱动程序已经被编译到内核中或作为模块被加载，而且udev 没有创建命名错误的设备。

如果驱动程序没有将它的信息导出到 sysfs，udev 就无法获得创建设备节点必需的信息。这种问题往往出现在内核源代码树以外的第三方驱动程序中。这时，需要在 /usr/lib/udev/devices 中使用正确的主设备号和次设备号，创建一个静态设备节点 (参考内核文档中的 devices.txt 或第三方驱动厂商提供的文档)，该静态设备节点将被复制到 /dev，udev 会自动完成复制。

9.3.3.7. 重启后设备命名顺序随机变化

这是由于 Udev 从设计上就是并行加载模块的，因此无法预测加载顺序。这个问题永远也不会被 “修复”。您不应该指望内核提供稳定的设备命名，而是应该创建您自己的规则，以根据设备的一些稳定属性，例如设备序列号或 Udev 安装的一些 *_id 工具的输出，来创建具有稳定名称的符号链接。可以参考第 9.4 节 “管理设备”和第 9.5 节 “一般网络配置”中的例子。