%general-entities; ]> Udev usage 在 中，我们在构建 eudev systemd 时安装了 Udev 软件包。在我们详细讨论它的工作原理之前， 首先按时间顺序简要介绍历史上曾经使用过的设备管理方式。 传统的 Linux 系统通常使用静态设备创建方法，即在 /dev 下创建大量设备节点 （有时有数千个节点），无论对应的硬件设备是否真的存在。 一般通过 MAKEDEV 脚本完成这一工作， 它包含以相关的主设备号和次设备号， 为世界上可能存在的每个设备建立节点的大量 mknod 程序调用。 使用 Udev 方法， 只有那些被内核检测到的设备才会获得为它们创建的设备节点。 由于这些设备节点在每次引导系统时都会重新创建， 它们被储存在 devtmpfs 文件系统中（一个虚拟文件系统，完全驻留在系统内存）。 设备节点不需要太多空间，它们使用的系统内存可以忽略不计。 在 2000 年 2 月，一个称为 devfs 的新文件系统被合并到 2.3.46 版内核中， 并在 2.4 系列稳定内核中可用。尽管它本身曾经存在于内核源代码中， 但这种设备节点动态创建方法从未得到内核核心开发者的大力支持。 devfs 采用的这种方法的主要问题是它处理设备的检测、创建和命名的方式， 其中最致命的是设备节点命名方式。一个被广泛接受的理念是， 如果设备名称是允许配置的，那么设备命名策略应该由系统管理员， 而不是某个（些）特定开发者决定。 devfs 还受到其设计中固有的竞争条件的严重影响， 在不对内核进行大量修改的前提下无法修复这一问题。 在一段时间后，由于缺乏维护，它被标记为过时特性，最终在 2006 年 6 月被从内核中移除。 在不稳定的 2.5 系列内核开发过程中，加入了一个新的虚拟文件系统， 称为 sysfs ， 并在 2.6 系列稳定内核中发布。 它的工作是将系统硬件配置信息导出给用户空间进程， 有了这个用户空间可见的配置描述，就可能开发一种 devfs 的用户空间替代品。 前面已经简要提到了 sysfs 文件系统。 有些读者可能好奇， sysfs 是如何知道系统中存在哪些设备，以及应该为它们使用什么设备号的。 答案是，那些编译到内核中的驱动程序在它们的对象被内核检测到时， 直接将它们注册到 sysfs （内部的 devtmpfs）。对于那些被编译为模块的驱动程序， 注册过程在模块加载时进行。只要 sysfs 文件系统被挂载好（位于 /sys），用户空间程序即可使用驱动程序注册在 sysfs 中的数据，Udev 就能够使用这些数据对设备进行处理 （包括修改设备节点）。 内核通过 devtmpfs 直接创建设备文件，任何希望注册设备节点的驱动程序都要通过 devtmpfs （经过驱动程序核心）实现。当一个 devtmpfs 实例被挂载到 /dev 时，设备节点将被以固定的名称、访问权限和所有者首次创建。 很快，内核会向 udevd 发送一个 uevent 事件。 根据 /etc/udev/rules.d、 /lib/udev/rules.d 以及 /run/udev/rules.d 中的规则，udevd 将为设备节点创建额外的符号链接，或修改其访问权限、所有者、属组， 或修改该对象的 udevd 数据库条目（名称）。 以上三个目录中的规则都被编号，且这三个目录的内容将合并处理。 如果 udevd 找不到它正在创建的设备对应的规则， 它将会沿用 devtmpfs 最早使用的访问权限和所有权。 编译为内核模块的设备驱动程序可能有内建的别名， 别名可以通过 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 支持加载模块。 当您插入一个设备，例如通用串行总线（USB) MP3 播放器时， 内核能够发现该设备现在已经被连接到系统，并生成一个 uevent 事件。 之后 udevd 像前面描述的一样，处理该 uevent 事件。 在自动创建设备节点时，可能发现一些问题。 Udev 只加载拥有总线特定别名，且总线驱动程序正确地向 sysfs 导出了必要别名的模块。如果情况不是这样， 您应该考虑用其他方法加载模块。在 Linux-&linux-version; 中， 已知 Udev 可以加载编写正确的 INPUT、IDE、PCI、USB、SCSI、SERIO 和 FireWire 驱动程序。 为了确定您需要的设备驱动程序是否包含 Udev 支持， 以模块名为参数运行 modinfo 命令。 然后试着在 /sys/bus 中找到设备对应的目录，并检查其中是否有 modalias 文件。 如果 sysfs 中有 modalias 文件，说明驱动程序支持该设备， 并能够直接和设备交互，但却没有正确地别名。这是驱动程序的 bug ， 您需要不通过 Udev 直接加载驱动，并等待这个问题日后被解决。 如果在 /sys/bus 下的相关目录中没有 modalias 文件， 说明内核开发者尚未对该总线类型增加 modalias 支持。 在 Linux-&linux-version; 中，ISA 总线不受支持。 只能等待这个问题在日后被解决。 Udev 根本不会尝试加载 snd-pcm-oss 等 包装器 驱动程序，或 loop 等非硬件驱动程序。 如果 包装器 仅仅用于增强其他模块的功能 （例如，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 中，作为单独的一行。包装器模块也可以被添加到这里， 但对于包装器来说这不是最好的方案。 不要构建该模块，或者在 /etc/modprobe.d/blacklist.conf 文件中禁用它。以 forte 为例， 下面一行禁用了该模块： blacklist forte 被禁用的模块仍然可以通过直接执行 modprobe 手动加载。 这一般是由于一条规则意外地匹配了某个设备。 例如，一个写得不好的规则可能同时匹配到 SCSI 磁盘（正确的） 和对应厂商的 SCSI 通用设备（不正确的）。 找到引起问题的规则，并通过 udevadm info 的帮助，将它进一步细化。 这可能是前一个问题的另一个表现形式。如果不是， 而且您的规则使用了 sysfs 属性， 这个问题可能由内核计时问题引发，这类问题需要在新的内核版本中修复。 目前，您可以创建一条规则以等待被使用的 sysfs 属性， 并将它附加到 /etc/udev/rules.d/10-wait-for-sysfs.rules 文件中（如果不存在就创建一个文件），绕过这个问题。 如果您通过这种方法解决了问题，请通知 LFS 开发邮件列表。 以下内容假设驱动程序已经被编译到内核中，或作为模块被加载， 而且您已经检查过并确认 Udev 没有创建命名错误的设备。 如果驱动程序没有将它的信息导出到 sysfs， Udev 就无法获得创建设备节点必需的信息。 这种问题往往出现在内核源代码树以外的第三方驱动程序中。 这时，需要在 /lib/udev/devices 中使用正确的主设备号和次设备号，创建一个静态设备节点 （参考内核文档中的 devices.txt 或第三方驱动厂商提供的文档），udev 会将该静态设备节点复制到 /dev 。 这是由于 Udev 从设计上就是并行加载模块的，因此无法预测加载顺序。 这个问题永远也不会被 修复。 您不应该指望内核提供稳定的设备命名，而是应该创建您自己的规则， 以根据设备的一些稳定属性，例如设备序列号或 Udev 安装的一些 *_id 工具的输出，来创建具有稳定名称的符号链接。 可以参考 和 中的例子。 以下链接包含了一些额外的帮助文档： A Userspace Implementation of devfs The sysfs Filesystem