# 7.4\. LFS 系统的设备和模块处理 在 [Chapter 6](../chapter06/chapter06.html) 里，我们安装了 Udev 软件包，在开始深入讨论它如何工作之前，我们先简要回顾一下以前处理设备的方法。 传统上一般 Linux 系统使用创建静态设备的方法，因此在 `/dev` 目录下创建了大量的设备节点(有时会有数千个节点)，而不管对应的硬件设备实际上是否存在。这通常是由 `MAKEDEV` 脚本完成的，这个脚本包含许多调用 `mknod` 程序的命令，为这个世界上可能存在的每个设备创建相应的主设备号和次设备号。而使用 udev 方式的时候，只有被内核检测到的设备才为其创建设备节点。因为每次系统启动的时候都要重新创建这些设备节点，所以它们被存储在 `tmpfs` 文件系统(一种完全存在于内存里，不占用任何磁盘空间的文件系统)上，设备节点不需要很多磁盘空间，所占用的内存可以忽略不计。 ## 7.4.1\. 历史 2000 年 2 月的时候，2.3.46 版本的内核引入了一种称为 `devfs` 的文件系统，在 2.4 系列稳定版本的内核中都是可用的。尽管它存在于内核源代码中，但这种动态创建设备的方法却从未得到核心内核开发者们的全力支持。 `devfs` 存在的主要的问题是它处理设备检测、创建和命名的方式，其中设备节点的命名可能是最严重的问题。一般可接受的方式是，如果设备名是可配置的，那么设备命名 策略应该由系统管理员决定，而不是由某些开发者强制规定。`devfs` 文件系统还存在竞争条件(race conditions)的问题，这是它天生的设计缺陷，不对内核做彻底的修改就无法修正这个问题。因为近来缺乏维护，它已经被标记为 deprecated(反对的)。 随着非稳定的 2.5 内核树的开发，即后来发布的 2.6 系列稳定版本内核，一种被称为 `sysfs` 的新虚拟文件系统诞生了。`sysfs` 的工作是把系统的硬件配置视图导出给用户空间的进程。由于有了这个用户空间可见的表示，代替 `devfs` 方案的时机就成熟了。 ## 7.4.2\. Udev 实现 #### 7.4.2.1. Sysfs 文件系统 上面简单的提到了 `sysfs` 文件系统，您可能想知道 `sysfs` 是怎么认出系统中存在的设备以及应该使用什么设备号。对于已经编入内核的驱动程序，当被内核检测到的时候，会直接在 `sysfs` 中注册其对象；对于编译成模块的驱动程序，当模块载入的时候才会这样做。一旦挂载了 `sysfs` 文件系统(挂载到 `/sys`)， 内建的驱动程序在 `sysfs` 注册的数据就可以被用户空间的进程使用，并提供给 `udev` 以创建设备节点。 #### 7.4.2.2\. Udev 启动脚本 `S10udev` 初始化脚本负责在 Linux 启动的时候创建设备节点，该脚本首先将 `/sbin/udevsend` 注册为热插拔事件处理程序。热插拔事件(随后将讨论)本不应该在这个阶段发生，注册 `udev` 只是为了以防万一。然后 `udevstart` 遍历 `/sys` 文件系统，并在 `/dev` 目录下创建符合描述的设备。例如，`/sys/class/tty/vcs/dev` 里含有"7:0"字符串，`udevstart` 就根据这个字符串创建主设备号为 _7_ 、次设备号为 _0_ 的 `/dev/vcs` 设备。`udevstart` 创建的每个设备的名字和权限由 `/etc/udev/rules.d/` 目录下的文件指定的规则来设置，这些文件以类似于 LFS 启动脚本风格的编号。如果 `udev` 找不到所创建设备的权限文件，就将其权限设置为缺省的 _660_ ，所有者为 _root:root_ 。 上面的步骤完成后，那些已经存在并且已经内建驱动的设备就可以使用了，那么以模块驱动的设备呢？ 前面我们提到了"热插拔事件处理程序"的概念，当内核检测到一个新设备连接时，内核会产生 一个热插拔事件，并在 `/proc/sys/kernel/hotplug` 文件里查找处理设备连接的用户空间程序。`udev` 初始化脚本将 `udevsend` 注册为该处理程序。当产生热插拔事件的时候，内核让 `udev` 在 `/sys` 文件系统里检测与新设备的有关信息，并为新设备在 `/dev` 里创建项目。 这样带来了 `udev` 存在的一个问题，之前 `devfs` 也存在同样的问题。这通常是个"先有鸡 还是先有蛋"问题。大多数 Linux 发行版通过 `/etc/modules.conf` 配置文件来处理模块加载，对某个设备节点的访问导致相应的内核模块被加载。对 `udev` 这个方法就行不通了，因为在模块加载前，设备节点根本不存在。为了解决这个问题，在 LFS-Bootscripts 软件包里加入了 `S05modules` 启动脚本，以及 `/etc/sysconfig/modules` 文件。通过在 `modules` 文件里添加模块名，就可以在系统启动的时候加载这些模块，这样 `udev` 就可以检测到设备，并创建相应的设备节点了。 注意，在慢速的机器上，或者对于需要创建大量设备节点的驱动程序，创建设备的过程可能需要好几秒钟，这意味着某些设备节点不能立即访问到。 #### 7.4.2.3.  设备节点创建 为了得到正确的主次设备号，Udev 依赖于 `/sys 目录下的` `sysfs 提供的信息。`例 如， `/sys/class/tty/vcs/dev` 包含字符串 "7:0"，被 `udevd` 用来创建主设备号是7、次设备号是0的设备节点。在 `/dev` 目录下创建的设备节点的名字和权限由`/etc/udev/rules.d/ 目录下相应的规则决定。`这 些以类似的形式包含在 LFS-Bootscripts 包中。 如果 `udevd` 不能为它现在创建的设备发现一个规则，它会默认把权限设置为 660 ，属主设置为 _root: root。_Udev 规则语法的文档可以查看 `/usr/share/doc/udev -096/index.html。` #### 7.4.2.4\. 模块加载 被编译成模块的设备驱动可能有编译进去的别名。别名可以通过 `modinfo` 程序的输出来查看，通常与设备总线特 有的标识有关（模块要支持）。例如，_snd-fm801_ 驱动支持 PCI 设备，通过生产厂商 ID 0x1319 和设备 ID 0x0801，有一个别名"pci:v00001319d00000801sv*sd*bc04sc01i*"。 对于大多数的设备，总线驱动通过 `sysfs` 导出可能会处理的设备驱动的别名。例如，`/sys/bus/pci/devices/0000:00:0d.0/modalias` 文件可能包含字符串"pci:v00001319d00000801sv00001319sd00001319bc04sc01i00"。 LFS 安装的规则会导致 `udevd` 调用 `/sbin/modprobe` 处理热插拔事件环境变量 `MODALIAS` 的内容（应该与 sysfs 中的 modalias 文件的内容一样）。 因此在通配符扩展之后，加载所有的别名匹配这个字符串的模块。 这个例子中，除了 _snd-fm801_，荒废的（不想要的） _forte_ 驱动会被加载（如果它是有效的）。 查看下面的方法来避免加载不想要的模块。 内核能在后台加载有关网络协议、文件系统和 NLS（国际语言支持） 支持的模块。 #### 7.4.2.5. 处理可热插拔/动态设备 当您插入一个设备，例如一个 USB 接口的 MP3 播放器，内核会检测到设备连接，并产生一个热插拔事件，如果驱动程序已经加载(要么是因为驱动已经编入内核，要么是已经通过 `S05modules` 启动脚本加载了)，`udev` 将被调用，并根据 `/sys` 目录下的 `sysfs` 数据来创建相应的设备节点。如果该设备的驱动是一个未加载的模块，将设备连接到系统上只会让内核的总线驱动产生一个热插拔事件，通知用户空间有新设备连 接，但并不加载驱动。事实上，什么都没有做，设备仍然不能使用。 如果刚才插入的设备有一个驱动程序模块但是尚未加载，Hotplug 软件包就有用了，它就会响应上述的内核总线驱动热插拔事件并加载相应的模块，为其创建设备节点，这样设备就可以使用了。 ## 7.4.3\. 创建设备的问题 自动创建设备节点的时候，存在一些已知的问题： #### 7.4.3.1. 内核模块没有自动加载 如果有一个总线特有的别名，并且总线驱动器导出必需的别名到 `sysfs，`那么 Udev 将只会加载一个模块。在其他情况下，需要安排其他的模块加载方式。在 Linux-2.6.16.27 中，Udev 为INPUT, IDE, PCI, USB, SCSI, SERIO 和 FireWire 设备加载适当的驱动。 为了确定你请求的设备驱动 Udev是否支持，可以以模块的名字为参数运行 `modinfo`。 现在把设置设备目录到 `/sys/bus` ，检测那里是否有一个 `modalias` 文件。 如果 `modalias` 文件存在于 `sysfs` 中，驱动程序支持设备可以直接通信，但是没有别名，这是驱动中的一个 bug。不利用 Udev 的帮助加载驱动，希望在以后这个问题会被修正。 如果在 `/sys/bus下的`相应目录内没有 `modalias` 文件，这就意味着内核开发者没有添加对这种总线类型的模块别名支持。在 Linux-2.6.16.27中，ISA 总线就是这种情况。希望在下个内核版本中会修正这个问题。 Udev 根本不会加载 "封装" 驱动像 _snd-pcm-oss_，和 非硬件驱动器像 _loop_。 #### 7.4.3.2. 内核模块没有自动加载，并且 Udev 也不加载 如果 “封装” 模块增强其他模块提供的功能（例如，_snd-pcm-oss_ 增强 _snd-pcm_ 的功能，使声卡对于 OSS 程序可用），配置 `modprobe` 使其在加载了相应模块后加载其封装模块。在 `/etc/modprobe.conf 中`添加一个 "install"  行来实现，例如： ``` install snd-pcm /sbin/modprobe -i snd-pcm ; \ /sbin/modprobe snd-pcm-oss ; true ``` 如果模块不是一个封装，而是对自己本身有用，配置 `S05modules` 启动脚本使其在系统启动的时候加载。 要实现这个，在 `/etc/sysconfig/modules 文件的相应行上添加模块的名字。`这对于封装模块也有用，但不是最优的。 #### 7.4.3.3. Udev 加载了不需要的模块 在下面例子中，对于 _forte 模块，可以_不编译它或者是在 `/etc/modprobe.conf 文件中`列入黑名单： ``` blacklist forte ``` 列入黑名单的模块仍然能够通过 `modprobe` 命令手工加载。 #### 7.4.3.4. Udev 错误的创建了设备或创建了错误的符号链接 如果规则匹配不是预想的设备，那么这种情况就会经常发生。例如，一个写的很糟糕的规则通过计算机提供商匹配到一个 SCSI 硬盘（期望的）和一个一般的 SCSI 设备（错误的）。找出这些不合格的规则，更正他们。 #### 7.4.3.5. Udev 规则工作不可靠 这或许是前面问题的一个表现。如果不是，你的规则使用 `sysfs` 属性，这可能是一个内核计时问题，在下个版本的内核中会被修正 。 现在，你可以通过创建一个等待使用 `sysfs 属性`的规则，把它添加到 `/etc/udev/rules.d/10-wait_for_sysfs.rules` 文件中。如果你做了，请通知 LFS 开发邮件列表 ，对他们有所帮助。 #### 7.4.3.6. Udev 没有创建设备 后面的文本假设驱动已经被静态的编译进了内核或者是作为模块已经被加载，你已经检查了 Udev 没有创建错误的设备。 某个内核驱动可能没有将其数据导出到 `sysfs`。这个问题在内核源代码树之外的第三 方驱动程序上尤其常见，结果是这些驱动无法创建其设备节点。用 `/etc/sysconfig/createfiles` 配置文件手动创建这些设备，参考内核文档里的 `devices.txt` 文件或者该驱动的文档以获得正确的主/次设备号。 静态的设备将会被 **S10udev 启动脚本**拷贝到 `/dev`。 #### 7.4.3.7. 重启后设备名字顺序变化 这是由于 Udev 设计的问题，它以并行方式处理热插拔事件和加载模块。因此名字的顺序就会不可预测。 这将不会被修正。你不应当依赖内核设备名字会稳定。相应的，根据设备稳定的属性（比如，序列号或者 Udev 安装的各种 *_id 工具的输出）写自己 的规则来创建符号链接。可以参见 [节 7.12, "为设备创建惯用符号连接"](symlinks.html "7.12\. 为设备创建惯用符号连接") 和 [节 7.13, "配置网络脚本"](network.html "7.13\. 配置网络脚本") 。