9.3. 设备和模块管理概述

第 8 章中,我们在构建 eudev 时安装了 Udev 软件包。在我们详细讨论它的工作原理之前,首先按时间顺序简要介绍历史上曾经使用过的设备管理方式。

传统的 Linux 系统通常使用静态地创建设备,即在 /dev 下创建大量设备节点 (有时有数千个节点),无论对应的硬件设备是否真的存在。一般通过 MAKEDEV 脚本完成这一工作,它包含以相关的主设备号和次设备号,为世界上可能存在的每个设备建立节点的大量 mknod 命令。

使用 Udev,则只有那些被内核检测到的设备才会获得为它们创建的设备节点。由于这些设备节点在每次引导系统时都会重新创建,它们被储存在 devtmpfs 文件系统中 (一个虚拟文件系统,完全驻留在系统内存)。设备节点不需要太多空间,它们使用的系统内存可以忽略不计。

9.3.1. 历史

在 2000 年 2 月,一个称为 devfs 的新文件系统被合并到 2.3.46 版内核中,并在 2.4 系列稳定内核中可用。尽管它本身曾经存在于内核源代码中,但这种设备节点动态创建方法从未得到内核核心开发者的大力支持。

devfs 实现机制的主要问题是它处理设备的检测、创建和命名的方式,其中最致命的或许最后一项,即设备节点命名方式。通常认为,如果设备名称是可配置的,那么设备命名策略应该由系统管理员,而不是某个 (某些)特定开发者决定。devfs 还受到其设计中固有的竞争条件的严重影响,在不对内核进行大量修改的前提下无法修复这一问题。由于缺乏维护,它早已被标记为过时特性,最终在 2006 年 6 月被从内核中移除。

在不稳定的 2.5 系列内核开发过程中,加入了一个新的虚拟文件系统,称为 sysfs,并在 2.6 系列稳定内核中发布。sysfs 的工作是将系统硬件配置信息导出给用户空间进程,有了这个用户空间可见的配置描述,就可能开发一种 devfs 的用户空间替代品。

9.3.2. Udev 实现

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/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. 加载模块和创建设备时的问题

在自动创建设备节点时,可能出现一些问题。

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

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

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

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

如果 modalias 文件不存在于 /sys/bus 下的对应目录中,说明内核开发者尚未对该总线类型增加 modalias 支持。在 Linux-5.10.17 中,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) man 手册页面,了解更多关于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 就无法获得创建设备节点必需的信息。这种问题往往出现在内核源代码树以外的第三方驱动程序中。这时,需要在 /lib/udev/devices 中使用正确的主设备号和次设备号,创建一个静态设备节点 (参考内核文档中的 devices.txt 或第三方驱动厂商提供的文档),该静态设备节点将被复制到 /devudev 会自动完成复制。

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

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

9.3.4. 扩展阅读

以下链接包含了一些额外的帮助文档: