linux 内核模块装载过程 [转]

原文地址：http://www.blogjava.net/alliciga/archive/2006/12/02/85055.html

前些日子公司的产品中需要安装一个显卡的驱动，而该驱动由两部分组成：内核模块、xorg Driver。由于产品系统是建立在小容量电子盘中的，所以无法通过运行驱动程序安装包来安装，因为要严格控制系统尺寸。所以只能是把模块和图形驱动都在 相同颁布的内核代码下编译好，再复制到目标平台上去。这样，就不会复制那些不必要的文档了。但是还有个问题，不同的 Linux 系统发布，有不同的内核模块装载方式。所以我就不得不仔细研究一下了。
    由于公司开发一般都是在 Fedora 平台上，而目标平台都是 LFS 系统，所以我们就这两个平台的装载方式进行一些探讨。
    首先，我们先来看看与发布平台无关的内核模块装载。
    内核引导的过程中，会识别出所有已经安装的硬件设备，并且创建好该系统中的硬件设备的列表树：/sys 文件系统。（udev 服务就是通过读取该文件系统内容来创建必要的设备文件的。）。根据 /sys 文件系统，内核读取 modules.alias 文件（位于 /lib/modules/2.6.16.27/ 目录下，2.6.16.27 为内核版本号，请替换为你的系统版本号），找到对应的模块，加载。我们可以看到 modules.alias 文件中都是类似如下的行：

    alias pci:v*d00008139sv00001186sd00001300bc*sc*i* 8139too

    中间的若干符号包含了很多信息，例如该设备的制造商编号、设备编号等。例如：

    alias pci:v00008086d00007190sv000015ADsd00001976bc06sc00i00

    表示该设备的设备编号是 0x7190，制造商编号是 0x8086，模块子系统提供商编号 0x15ad 等等，v即是代表 vendor，sv代表 subsystem-vendor，sd代表 subsystem-device。

    通过这些信息和 modules.alias 某一行匹配之后，便加载后面指定的模块名称。加载模块使用的是 modprobe 工具。我们可以发现，modules.alias 文件中给出的模块只是个名称，并没有模块文件的绝对路径。那么 modprobe 工具如何定位模块文件本身呢？它需要另一个有用的文件：modules.dep 。该文件和 modules.alias 在同一个目录下。该文件的内容是像下面一样的行文本：

    /lib/modules/2.6.16.27/kernel/drivers/net/8139too.ko : /lib/modules/2.6.16.27/kernel/drivers/net/mii.ko

    当内核通过 modules.alias 文件确定需要加载 8139too 模块时，调用 modprobe 8139too，modprobe 工具再通过读取 modules.dep 文件找到 8139too.ko 行，冒号前的文本给出了该模块的绝对路径，而后面的文本则是在加载该模块前需要先行加载的模块，也就是它所依赖的模块。（模块的依赖性不属于本文范围，所 以不做细致讨论）
    以上讨论的是内核启动中，发现硬件，并且成功匹配模块名称并加载的情况。但如果内核没有成功匹配合适的模块呢？我们就需要作一些工作自己加载了。
    当然，我们可以每次手动调用 insmod 加载某个模块，但如果是硬件设备驱动的话，我们自然更愿意让它在系统引导时便加载。
    对于这个问题，Fedora 和 LFS 的做法是不同的。
    Fedora 在 core 3 之后的版本中，加入了 /etc/modprobe.conf 文件，我们可以在该文件中加入我们自己的模块的 alias 行。该文件的作用是在 modprobe 运行时，添加必要的模块参数、修正模块加载方式或使用更为灵活的模块加载办法，例如加入安装脚本。
    而 LFS 则使用了特意订制的一个服务 S05modules，读取配置文件 /etc/sysconfig/modules，加载其中以行指定的模块名称，不过只是简单地调用 modprobe。如果我们要加入非系统直接支持的硬件的话，则需要修改相应的 modules.dep 文件，以便 modprobe 工具可以正确的识别模块的绝对路径。