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%。