7.3. 设备和模块管理概述

7.3.2.1. Sysfs

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

7.3.2.2. 设备节点的创建

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

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

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

7.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 以 MODALIAS uevent 环境变量的内容 （应该和 sysfs 的 modalias 文件内容一致）调用 /sbin/modprobe，并加载在通配符扩展后， 别名能够匹配该字符串的所有模块。

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

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

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

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

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

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

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

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

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

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

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

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

softdep snd-pcm post: snd-pcm-oss

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

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

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

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

blacklist forte

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

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

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

7.3.3.5. Udev 规则工作不可靠

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

7.3.3.6. Udev 没有创建设备

以下内容假设驱动程序已经被编译到内核中，或作为模块被加载， 而且您已经检查过并确认 Udev 没有创建命名错误的设备。

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

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

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