linux 3.4内核初始化,Linux内核源代码分析-第四章 系统初始化-3

4.2.2 分析内核选项

parse_options函数分析由内核引导程序发送给内核的启动选项，在初始化过程中按照某

些选项运行，并将剩余部分传送给init进程(在本章后面部分提到)。这些选项可能已经

存储在配置文件中了，也可能是由用户在系统启动时敲入的—内核并不关心这些。类似的

细节全部是内核引导程序应该关注的内容。

1. parse_options

19707：参数已经收集在一条长的命令行中，内核被赋给指向该命令行头部的一个指针；

内核引导程序在前面已经将该行存储在一个指定地址中。

19718：中断下一个参数，保持指向下一个参数的指针以供下一次循环使用。注意系统使

用空格而不是通常的空白来分隔内核参数；制表符并不能把当前参数和下一个参数分隔开

。如果发现了分隔字符空格，下一行就使用字节0覆盖，这样line可以作为包含有唯一一

个内核选项的标准C字符串来使用了。如果没有发现空格，就该函数关心的内容而言，其

余的部分都具有相同的属性—这只有在处理line中最后一个选项的情况下才会发生，循环

就会在下次开始时结束。

注意该代码不会跳过多个空格。假设line值如下所述(两个空格)：

rw debug

这会被当作三个选项：“rw”、“”(空字符串)和“debug”。因为空字符串不是有效

的内核选项，它将会被传递到初始化的过程(这一点随后就可以看到)—这当然不是用户

所希望的。因此，内核引导程序应该负责对多个空格进行压缩。LILO通过忽略用户多敲的

空格，完美地解决了这个问题。

19721：现在开始解释这些选项。最前面的两个选项ro和rw指明内核要装载根文件系统，

也就是根目录( / 目录)所在的位置，而分别处于只读和读/写模式。

19729：第三种可能性，debug，增加了调试信息的数量；这些调试信息要通过调用

do_syslog打印出来(25724行)。

19733：开始几个选项是简单的独立标志，它们并不使用参数。内核也可以辨认形为

option=value的选项。本行就是一个例子，这里内核引导程序定义了一个命令来代替init

运行；它使用init=/some/other/program的形式。这里的代码舍弃了init= 部分，为随后

init的使用而把剩余部分在execute_command中保存起来(20044行)。和其他大部分参数

的处理方法不同，本处功能不能在checksetup(19612行)中实现，这是因为它改变了该

函数的局部变量。很快，你就可以看到前面三个选项之所以也在这里处理，而不是在

checksetup中处理的原因。

19745：大部分内核选项都是由checksetup函数分析的。如果checksetup处理了某个选项

，就返回真值，循环继续进行。

19750：否则，line中没有已经被辨认的内核选项。在这种情况下，它被作为一个供init

进程使用的选项或者环境变量来处理—如果其形式为envar=value，就作为环境变量处理

；否则，就作为选项处理。如果argv_init和envp_init(分别见19057和19059行)数组中

有足够的空间，选项和环境变量就存储在里面供以后init函数使用。

这解释了从19736行开始的注释。字符串auto并不是任何内核选项的前缀，因此它应该被

作为init的一个参数存储在argv_init数组中—这在大多数情况下都是可行的，因为auto

是init可以识别的选项。但是，当使用init=的形式给出内核选项时，通常是执行shell而

不是init，auto会使shell混淆；因此，安全一点的方法是，parse_options在此处忽略所

有与此有关的init参数。

奇怪的是，当argv_init或者envp_init数组空间用完时，整个循环就结束了。仅仅因为

argv_init的空间用完了并不意味着line中就不再含有init使用的环境变量，反之亦然。

此外，可能还剩下许多内核选项没有处理。当你考虑到MAX_INIT_ARGS(19029行)和

MAX_INIT_ENVS(19030行)都通过使用#define被预定义为8—这是一个很容易超过的下限

，这种行为就更奇怪了。如果在19752行和19756行的break改成continue，那么循环可以

继续处理内核选项，而不会写入超过argv_init和envp_init数组界限的空间。如果

command_line中仍然包含有并不是为init而定义的内核选项，那么这一点就是非常重要的

。

19760：所有的内核选项都处理完成了。最后一步是要使用NULL填充argv_init和

envp_init数组的末尾，从而使得init可以知道在哪里终止。

2. checksetup

19612：checksetup函数负责进行大部分内核选项的处理过程。它把这些内核选项分为三

类：一类使用内核普通参数来分析=sign之后的部分；另一类自行分析=sign之后的部分；

还有一类自行分析整个行，包括= sign前面的部分和= sign后面的部分。第一类被认为是

使用“现成”的参数，这与为第二类提供的“原始”参数相对应。最后一类只由一个IDE

驱动程序组成；内核首先在19619行检查并处理这种情况，以使其不会在随后的处理中造

成麻烦。

19625：接下来，checksetup扫描整个raw_params数组(19552行),并判断是否该内核选

项应该不加处理地保留。raw_params中的元素是struct kernel_param类型(19223行)的

，它把内核选项前缀和装载选项时调用的函数联系起来。如果数组中的某些项的str成员

以line为前缀，就会调用line后面的相应函数(也就是前缀之后的部分)，随后

checksetup会返回一个非零值以表明它已经对该内核选项进行了处理。raw_params数组以

两个NULL结束，因此在检测到str成员是NULL时，循环就可以结束了。在这种情况下，显

然循环已经到达了raw_params数组的结尾，但是仍然没有找到匹配的情况。当然，测试

setup_func成员也可以取得同样好的效果。

这个循环说明了一点：与大多数内核非常不同的是，这里的初始化并不需要尽可能地快。

如果内核比从前多用几微秒来启动，这并没有什么实际的损失—毕竟用户应用程序还没有

开始运行，所以他们并没有损失什么东西。

最终结果是代码效率很低，而且存在很多优化的可能。例如，raw_params数组中字符串的

长度可以在raw_params中暂存，而不用在19626行多次重复计算。更好的解决方法是，可

以把raw_params数组中的项按照字符顺序排序，这样checksetup就可以进行折半查找。

在raw_params的情况中实现排序并没有什么障碍，但是这样也可能并不能获得很大的优势

，因为折半查找的优点只有在比较大的数组中才能充分表现出来(所谓比较大的确切值在

不同的环境中也有所不同)。raw_params的姊妹数组cooked_params(19228行)当然是足

够大的，可以显示出折半查找的优势；但是这样就引发了一个新的问题：对

cooked_params进行排序比较难用，因为这可能需要分隔一些#ifdef程序段—请参看从

19268行到19272行的例子。进一步说，因为算法只是查找前缀，而不使用完全匹配，在遍

历数组中的各个项时对遍历次序比较敏感，所以这种特性在使用不同的查找次序时就很难

再保持了。然而，这些问题并不是不可克服的(程序员可以预先静态地为引导程序建立一

颗前缀树)，如果性能在这里是主要因素，那么这种努力也是值得的。但是，由于性能在

这里并不是主要问题，所以简单性才被作为最重要的因素体现出来。

即使这样，在类似的root_dev_names数组(19085行)中—这个数组把硬件设备名的前缀

映射到它们的主ID号上，开发者仍然可以简单地通过把比较常用的项(IDE和SCSI磁盘)

放在不太常用的项(并口IDE CD)的前面以节省出一点性能。但是我在raw_params或

cooked_params中并没有发现与之类似的模式。

另外一件需要注意的事是：现在你可以猜想一下为什么ro、rw和debug选项在

parse_options中测试而不在这里测试，parse_options要检测精确的匹配，但是

checksetup只检测前缀。作为一个特殊的情况，ro选项碰巧正好是root=(19553行)的前

缀，这样如果这三个选项彼此合并，就需要仔细处理了。这似乎仍然是一个相当无力的原

因。考虑一下noinitrd选项(19251行)。这是cooked_params的一个项，因而只需要匹配

前缀，而且与之相关联的设置函数(no_initrd，19902行)将忽略所有可能已经传递给它

们的参数—这正像ro、rw和debug被包含在cooked_params中时所可能进行的工作一样。

19632：这个循环为cooked_params数组的处理工作和前面一个循环为raw_params数组的处

理工作相同。这两个循环(当然不包括循环使用的数组)间的唯一区别是本循环在调用设

置函数之前，使用get_options(19062行)处理line中=sign后面的部分。简单地说，

get_options使用10个负整数填充ints[1]到ints[10]。ints[0]中是ints中使用元素的个

数—也就是，它记录了存储在ints中的ints get_options数量。接着这个数组将被传递给

设置函数，该设置函数则会按照自己喜欢的方式对该数组内容进行解释。

19640：返回0，说明line中所包含的内核选项不能被函数理解。

3. profile_setup

19076：profile_setup是checksetup调用的设置函数的一个完美的例子：这个函数十分短

小，使用ints参数处理了部分内容。而且到目前为止你也应该对它的目的有了一定了解。

正如前面提到的一样，用户可以在启动的时候设置prof_shift的值—这里正是它的实现方

式。当内核启动过程提供profile=选项时，就调用profile_setup函数。前缀字符串和函

数在19235行被联系在一起。注意这是在cooked_params中，因此profile_setup取得的是

处理过的参数。

19079：如果参数中存在profile=的形式，就使用profile=后面的第一个数字作为

prof_shift的新值。选项给出的其他参数都被简单地忽略了。

19081：如果给出了profile=选项，但是没有为它提供参数，prof_shift的缺省值就是2。

这个缺省值有些奇怪，因为我们已经知道，这意味着使用四分之一的内核可用内存来配置

其余部分—这是一个很大的开销。但是另一方面，使用这些内存有助于更精确地定位问题

热点—只有很少的几条指令存在不确定性，这样应该比较容易地把问题限制在一两行源程

序代码内。那张图也并不是像我所画的那样简单：因为图中只描述了内核代码，这种开销

还不到内核所有内存空间的25%，但是对于所覆盖的代码量来说却并不止25%。