kerneld和高级模块化.docVIP

第11章 kerneld和高级模块化 在本书的第二部分，我们要讨论的话题比到目前为止我们所接触过的话题都更为高级。我们将再次从模块化讲起，第二章“编写和运行模块”中对模块化的介绍只是其中的一部分；modules包(它们的必威体育精装版版本被称作modutils)支持一些更高级的特性，它们比前面讨论的安装和运行一个基本的驱动程序所需的特性要更为复杂。 本章将讨论kerneld程序，模块中的版本支持(一种便利性，它使你在升级内核时不必重新编译你的各个模块)以及在卸载和重新装载一个模块时对数据持久性的支持。最后这项功能只有2.0.0版或更新版本的modules包才提供。 按需加载模块 为了方便用户加载和卸载模块，并且避免把不再使用的驱动程序继续保留在核心中浪费内核存储空间，Linux提供了对模块的自动加载和卸载的支持。(在1.2版以前不提供这种支持)要利用这个特性，在编译内核前进行的配置中你必须打开对kerneld的支持。需要时可以请求附加模块的能力对于使用堆叠式模块的驱动程序尤其有用。 隐藏在kerneld之后的思想很简单，但却很有效。当内核试图访问不可用资源时，它会通知用户程序而不仅仅是返回一个错误。如果守护进程成功地获得该资源，内核将继续工作；否则它将返回错误。实际上申请任何一种资源的时候都可以使用这种办法：诸如字符设备和块设备驱动程序，行律和网络协议等等。 用于获得按需装载能力的机制是使用一个修改过的消息队列，利用它在内核空间和用户空间之间相互传递文本信息。要让按需装载能正确工作，必须正确地配置用户级守护进程，并且内核代码必须做好准备，等待所需的模块。 可以从按需装载中受益的驱动程序的一个典型例子是通用帧捕获者(frame-grabber)驱动程序。它能支持几种不同的外设，但却表现出相同的外部行为。发布中将包括它所支持的所有设备卡的代码，但是在运行时只有正在被使用的那个特定设备卡的代码才真正需要。这样开发者就能够把具体实现划分为一个定义软件接口的通用模块和一系列用于低层操作的与硬件相关的模块。在通用模块检测到系统中安装的捕获者的类型后，它就能够为该捕获者申请正确的模块。 用户级方面 kerneld程序生存在用户空间，负责处理来自内核的对新模块的请求。它通过创建自己的消息队列和内核相连，然后进入睡眠，等待请求。 请求一个模块时，守护进程从内核中接收一个字符串并试图解析它。这个字符串可能是下面两种形式之一： 目标文件的名字，就象insmod命令的典型参数一样。floppy是这种名字的一个例子；在这种情况下，守护进程将查找文件floppy.o并装载它。 更一般的标志符，比如block-major-2，它用来指明主设备号为2的块设备－也就是软盘驱动程序。这种类型的字符串是最常见的，因为内核通常只知道资源的数字标志符。例如，当你试图使用一个块设备时，内核只知道它的主设备号；仅仅就为了能通过名字来请求每个块设备而为它们实现各自不同的钩子函数很浪费。 显然，后一种情况时，必须有某种方法把模块的id映射成它的实际名字。这种关联并不由kerneld本身完成而是由kerneld调用modprobe来完成。在depmod命令的帮助下，由modprobe来处理模块装载的细节；kerneld本身只负责与内核的通讯并生成外部任务。所有这些程序都在modules包中一起发布。depmod是一个能产生类似Makefile那样的模块依赖信息的工具，而modprobe是能替代insmod用来正确装载模块堆栈的程序。例如ppp模块堆叠在slhc模块(Serial Line Header Compression)之上(换句话说，可以使用slhc模块中的符号)。除非已经装载了slhc，否则命令insmod ppp就会失败；另一方面，假如在安装好模块之后会调用命令depmod -a来创建依赖规则，命令modprobe ppp就能成功。 insmod和modprobe间的另一个差别是后者不会在当前目录中查找模块，它只在/lib/modules下的缺省目录中查找。这是因为该程序是一个系统实用例程，而不是一个交互工具；你可以通过在/etc/modules.conf中指定你自己的目录，来把它们加入缺省目录集。 /etc/modules.conf是一个用于定制modules包的文本文件。它负责把象block-major-2这样的名字关联到floppy。注意，2.0前的版本的modules包查找的是另一个文件/etc/conf.modules；出于兼容的考虑，仍支持这种文件名，但提倡更为标准的名字modules.conf。 modules.conf的语法在depmod和modprobe命令的man页中有很好的描述；然而，我觉得有必要在这里提及一些重要命令的意思。我用下面几行作为例子：