【翻译】内核组件初始化体系结构

为了全面了解内核组件，你不仅需要了解特定的程序做了什么，也要知道这些程序什么时候被谁调用。内核子系统的初始化是一项基本任务，这些任务由内核根据它自己的模式来处理。这个体系结构值得我们学习并有助于理解网络堆栈的核心组件，包括网络设备驱动程序是如何初始化的。

本章的目的在于展示内核怎样处理用于初始化内核组件的函数，既包含静态嵌入内核的组件，也包括作为内核模块加载的组件，特别是网络设备。我们将会弄明白如下几点：
l 初始化函数是如何被特殊的宏来命名与标识
l 这些基于内核配置的宏如何被定义，以优化内存使用，确保各种初始化以正确的顺序被执行
l 函数什么时候、怎样执行

我们并不讨论初始化体系结构的所有细节，不过你可以快速浏览一遍并舒适的阅读源代码了

7.1、启动时内核选项

Linux允许用户传递内核配置选项给启动程序，启动程序再把这些选项传递给内核。有经验的用户可以利用这个机制在系统启动时调整内核。在启动阶段，内核有两次调用parse_args函数(译者注：本书是基于2.6内核，在2.4内核中采用parse_options函数)处理启动时的配置输入。接下来我们在“两次调用解析中解释”parse_args为何被调用两次。

你可以在Linux BootPrompt HOWTO中找到一些使用启动选项的文档或例子

parse_args是解析具有形如“变量名=值”的输入字符串的函数，它查找关键字并调用相应的处理函数。在加载模块、解析模块命令行参数时，parse_args也会被调用。

我们不必知道parse_args如何实现解析功能的细节，但是我们对内核组件如何为关键字注册处理函数以及处理函数如何被调用感兴趣。为了有一个清晰的认识，我们需要了解：
l 在启动字符串中含有关键字时，内核组件如何注册关键字及相对应的执行函数
l 内核如何解析关键字和处理函数之间的关联关系，我们将提供一个内核如何解析输入字符串的高级用法。
l 网络设备子系统如何使用这个特性

所有的解析代码都在kernel/params.c中，我们在接下来的部分逐步讲述。

7.1.1、注册关键字
内核组件用__setup宏来注册关键字及相关联的处理函数，__setup宏在include/linux/init.h中定义，其原型如下：
__setup(string, function_handler)
其中：string是关键字，function_handler是关联处理函数。__setup只是告诉内核在启动时输入串中含有string时，内核要去执行function_handler。String必须以“=”符结束以使parse_args更方便解析。紧随“=”后的任何文本都会作为输入传给function_handler。
下面的例子来自于net/core/dev.c，其中netdev_boot_setup作为处理程序被注册给“netdev=”关键字：
__setup("netdev=", netdev_boot_setup);
不同的关键字可以注册相同的处理函数，例如在net/ethernet/eth.c中为“ether =”关键字注册了同样的处理函数netdev_boot_setup。当代码作为模块被编译时，__setup宏被忽视，你可以在include/linux/init.h中看到__setup宏是怎样变化的，不管后续包含它的文件是否是模块，include/linux/init.h都是独立的。
start_kernel两次调用parse_args解析启动配置字符串的原因是启动选项事实上分为两类，且每次调用值能够兼顾到其中一类：

缺省选项：
绝大多数选项归于此类，这些选项由__setup宏定义并在第二次调用parse_args时处理。
先期(处理)选项：
在内核启动阶段，有些选项要在其它选项之前被处理，内核提供了early_param宏以代替__setup宏申明此类选项。这些选项由parse_early_params函数解析。early_param宏和__setup宏仅有的不同就是前者设置了一个特殊标志让内核能够区分两种不同的状况。这个标志是我们将在“.init.setup内存区”小节中看到的obs_kernel_param结构的一部分。
启动时选项在内核2.6中的处理方式已经改变，但并非所有的内核代码都因此而更新。在最近一次改变之前，还仅用__setup宏。因此，遗留下来将被更新的代码现在使用__obsolete_setup宏。但用户用__obsolete_setup宏定义的选项给内核时，内核打印一条警告消息说明它已是废弃状态，并提供一个文件指针和随后被公告的源代码行信息。
图7-1概述了几个宏之间的关系：它们都包裹了普通的__setup_param函数。

图7-1 setup_param宏及其包裹物


注意：传给__setup宏的程序被放到.init.setup内存节，这样，在“启动时初始化代码”一节中可以很清晰的看出这样做的效果。

7.1.2、两次解析
因为早期的内核版本(译者注：所谓的早期是相对于2.6内核而言的)中，启动时选项用于做不同的处理，并且这些选项没有全部移植到新的内核版本，所以新内核要处理这两者情况。当新的体系结构不能够识别关键字，它会采用废弃的体系结构来处理。当废弃的体系结构也处理失败时，系统将把关键字和值一起由run_init_process函数传递给init进程处理，而init进程是在init内核线程处理后期被调用。然后关键字和值要麽被加入到arg参数列表，要麽被加到envp环境变量列表。
前面解释了，为了支持先期选项以特定的顺序提前处理，启动串解析和处理调用被做了两次,如图7-2所示(此图是第五章介绍的start_kernel的快照)：
1、第一次处理看上去似乎是有特殊标记标识的高优先权的选项先处理(early标志)
2、第二次处理其它的选项，绝大多数选项归于此类，废弃的所有选项都在这次被处理。
第二次首先检测在新体系结构下是否有匹配的选项处理，这些选项存储在kernel_param结构中，由第五章介绍的module_param宏填充。module_param宏还确保所有的这些结构数据被放到特殊的内存节(__param)，并由__start___param 和 __stop___param指针分隔。
当识别了这些选项时，相关参数被初始化给选项的值，即启动选项串的function_handler；而当没有选项匹配时，unknown_bootoption函数试着看是否废弃的处理模型能够处理这些选项，如下图示：

图7-2 两次调用选项解析


废弃的和新模型选项放在两个不同的内存区：

__setup_start ... __setup_end：
我们在后面的章节中会看到，这个区域在启动阶段结束时被释放：一旦内核启动，这些选项就不在需要，用户也不能够在运行时查看或修改它们。
__start___param ... __stop___param：
这个区域不会被释放，它的内容被导入/sys文件系统，以暴露给用户。
第五章有更多关于模块参数的细节。

注意：所有作废模式选项，不管它是否有优先处理的特殊标志，都被放到__setup_start和__setup_end内存区。

7.1.3、.init.setup内存区

我们前面章节介绍的传给__setup宏的两个输入参数被放入obs_kernel_param类型的数据结构中，它在include/linux/init.h中定义:

struct obs_kernel_param {
const char *str;
int (*setup_func)(char*);
int early;
};
其中，str是关键字，setup_func是处理函数，early是“两次解析”小节中介绍的两次调用中的特殊标志。
__setup_param宏把所有的obs_kernel_params实例放到专门的内存区，这样做主要有两个原因：
l 当查找基于str的关键字时，通过所有的实例，系统更容易处理具体的实例。我们将明白在查找关键字时内核如何使用分别代表先前提及的内存区的开始和结束的__setup_start 和 __setup_end两个指针。
l 当不再需要时，内核能够快速释放所有数据结构。我们可以在后面要讲的“内存最优化”小节看到这点。

7.1.4、用启动选项配置网络设备

按照前面章节所述，我们接下来看看网络代码怎样使用启动选项的。

我们在“注册关键字”一节中注意到ether= 和 netdev=关键字都用同一函数netdev_boot_setup注册。当调用netdev_boot_setup函数处理输入参数(紧随匹配的关键字后的字符串)时，函数将把处理结果存储在include/linux/netdevice.h中定义的netdev_boot_setup结构中，处理函数和结构碰巧是同名的，因此你要注意不要混淆两者：
struct netdev_boot_setup {
char name[IFNAMSIZ];
struct ifmap map;
};
其中，name是设备名，ifmap在in include/linux/if.h中定义，是存储输入配置的数据结构：
struct ifmap
{
unsigned long mem_start;
unsigned long mem_end;
unsigned short base_addr;
unsigned char irq;
unsigned char dma;
unsigned char port;
/* 3 bytes spare */
};

同一关键字可以在启动时字符串选项中多次出现(对不同设备)，如下例所示：
LILO: linux ether=5,0x260,eth0 ether=15,0x300,eth1
但是，这种机制下，能够在启动时配置的设备的最大数是NETDEV_BOOT_SETUP_MAX常量，它也是用于存储配置的静态数组dev_boot_setup的大小：
static struct netdev_boot_setup dev_boot_setup[NETDEV_BOOT_SETUP_MAX];

netdev_boot_setup相当简单：它从字符串中提取输入参数中，填充到ifmap结构中，并通过netdev_boot_setup_add函数将ifmap信息加入到dev_boot_setup数组中。
启动阶段结束时，网络代码会调用netdev_boot_setup_check函数检查给定的接口是否与启动时配置有关联，在dev_boot_setup数组中查找时基于设备名dev->name:

int netdev_boot_setup_check(struct net_device *dev)
{
struct netdev_boot_setup *s = dev_boot_setup;
int i;

for (i = 0; i < NETDEV_BOOT_SETUP_MAX; i++) {
if (s[i].name[0] != '\0' && s[i].name[0] != ' ' &&
!strncmp(dev->name, s[i].name, strlen(s[i].name))) {
dev->irq = s[i].map.irq;
dev->base_addr = s[i].map.base_addr;
dev->mem_start = s[i].map.mem_start;
dev->mem_end = s[i].map.mem_end;
return 1;
}
}
return 0;
}

有些设备具有特殊容量、特征与限制，在需要额外的参数时，可以定义它自己的关键字和处理函数，这些关键字和函数紧接着ether= 和 netdev=提供的基本数据之后(PLIP设备驱动程序就是这样做的)

7.2、模块初始化代码

由于下面的章节的例子经常提及模块，所以有必要弄清楚一对初始化概念：
内核代码要麽静态连接到主映象文件，要麽在需要时作为模块动态加载。并不是所有的内核组件都适合编译成模块，设备驱动程序和基本功能扩展是内核组件被编译为模块的一个好的例子。你可以参考Linux Device Drivers一书了解模块利弊以及内核需要时动态加载模块而不再需要时卸载模块的原理。

每个模块都必须提供两个函数：init_module 和 cleanup_module，前者在模块加载时初始化模块，后者在内核卸载模块时被调用以释放被模块使用时分配的资源(包括内存)。

内核提供了两个宏：module_init 和 module_exit，它允许开发人员随意命名初始化和卸载函数，下面是3COM公司的3c59x网卡驱动(drivers/net/3c59x.c)中的一个例子：
module_init(vortex_init);
module_exit(vortex_cleanup);
在“内存最优化”一节，我们将看到这两个宏如何定义以及其定义如何被内核配置项所改变。绝大多数内核使用这两个宏，但极少数模块仍然使用旧的缺省名init_module 和 cleanup_module。在本章后续内容中，我们用module_init 和 module_exit来指代初始化和卸载清除函数。

首先我们来看看用旧的内核模型是如何编写模块初始化代码的，然后看看基于新的宏集的内核如何工作的。

7.2.1、旧模式：条件编译代码

不管内核组件是编译成模块还是静态编译到内核中，它都需要初始化。因此，内核组件初始化代码必须依靠条件指示符告诉编译器区分这两种情况。在旧模式下，这将强迫开发者在所有这些地方使用类似#ifdef的条件编译指示符。

下面是2.2.14内核3c59x网卡驱动(drivers/net/3c59x.c)中的一段：注意#ifdef MODULE 和 #if defined (MODULE)使用了多次。

...
#if defined(MODULE) && LINUX_VERSION_CODE > 0x20115
MODULE_AUTHOR("Donald Becker <becker@cesdis.gsfc.nasa.gov>");
MODULE_DESCRIPTION("3Com 3c590/3c900 series Vortex/Boomerang driver");
MODULE_PARM(debug, "i");
...
#endif
...
#ifdef MODULE
...
int init_module(void)
{
...
}
#else
int tc59x_probe(struct device *dev)
{
...
}
#endif /* not MODULE */
...
static int vortex_scan(struct device *dev, struct pci_id_info pci_tbl[])
{
...
#if defined(CONFIG_PCI) || (defined(MODULE) && !defined(NO_PCI))
...
#ifdef MODULE
if (compaq_ioaddr) {
vortex_probe1(0, 0, dev, compaq_ioaddr, compaq_irq,
compaq_device_id, cards_found++);
dev = 0;
}
#endif

return cards_found ? 0 : -ENODEV;
}
...
#ifdef MODULE
void cleanup_module(void)
{
... ... ...
}
#endif

上面代码表明旧模式如何让程序员根据代码是编译成模块还是静态连接到内核映象来指定做不同的事情：
初始化代码被区别执行
代码显示cleanup_module函数仅当驱动程序被编译成模块时被定义(因此被使用)
代码块被包含或排斥在模块之外
例如：仅当驱动程序被编译成模块时vortex_scan 调用 vortex_probe1

这种模型使代码很难扩展与调试，而且在每个模块中都重复相同的逻辑。

7.2.2、新模式：基于宏的标记

现在我们来对比一下上节代码与2.6内核中相匹配的同样的文件

static char version[] _ _devinitdata = DRV_NAME " ... ";

static struct vortex_chip_info {
...
} vortex_info_tbl[] _ _devinitdata = {
{"3c590 Vortex 10Mbps",
... ... ...
}

static int _ _init vortex_init (void)
{
...
}
static void _ _exit vortex_cleanup (void)
{
...
}

module_init(vortex_init);
module_exit(vortex_cleanup);

你可以看到：#ifdef指示符不再需要。
为了移除这些混乱的条件编译代码，以使代码有良好的可读性，内核开发者引入了一组模块开发者现在能够用于写更清晰初始化代码的宏(绝大多数驱动程序都是这些宏的使用者),上述代码展示了其中的几个宏：__init, __exit, 和 __devinitdata的用法。

后面的章节将讲述这些宏如何被使用以及它们是如何工作的。

对每个模块来说，这些宏允许内核在后台决定那些代码被包含在内核映象中，那些代码因为不需要被排斥，那些代码仅仅在初始化时被执行，等等。这样就去除了每个程序员在每个模块都要复制相同的逻辑的麻烦。