4.txt

Linux内核源代码分析/电子书

这解释了从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%。
4.3   init
init从许多方面看都是一个非常特殊的进程。这是内核运行的第一个用户进程，它要负责触发其他必需的进程以使系统作为一个整体进入可用的状态。这些工作由/etc/inittab文件控制，通常包括设置getty进程以接受用户登录，建立网络服务，例如FTP和HTTP守护进程，等等。如果没有这些进程，用户就不可能完成很多工作，这样成功启动内核就显得没有多大意义了。
这种设计的另外一个主要的副作用是init是系统中所有进程的祖先。init产生getty进程，getty进程产生login进程，login进程产生你自己的shell，使用自己的shell，可以产生每一个你运行的进程。在所有的结果中，这有助于确保内核进程表中的所有项最终都能够得到处理。进程结束以后将其清除（回收）的工作首先应由其父进程完成；如果父进程已经退出，那么祖父进程就要担负起这种责任；如果祖父进程已经退出，那么曾祖父进程就要担负起这种责任，周而复始。通过这种方式，从不退出的init进程就可能要负责回收其他进程。
因此，为了确保这些重要的工作都能正确执行，内核初始化进程所需要做的最后一步工作就是创建init进程，接下来就加以描述。
 init
20044：unused参数来源于该函数的非常规调用。init函数—不要和init进程搞混了，后者是它随后要创建的—作为内核线程开始生命周期，一个作为内核的一部分运行的进程（如果你编写过多线程的程序，这里的内核线程可能会同你所已经知道的线程意义有所不同—在那种意义下，它不是一个内核线程）。实际上，init函数就像是新进程使用的剥离出来了的main函数，unused参数是一个独立的指针，其值指向为给定进程所提供的信息—这比通常使用argc、argv和envp参数传递的信息要少得多。init函数碰巧不需要额外的信息，这个参数命名为unused，就是要强调这一点。
为了确保在这一点上你不会产生困惑，我们在这里再对整个机制进行扼要重复：init函数是内核的一部分；它在内核中作为内核的一个独立的执行部分运行；也就是说，无论从哪个方面看它都是内核代码。但是，init进程就不是这样了。在某些方面，init进程是一个特殊的进程，但是不属于内核本身；其代码存储在磁盘上单独的可执行映像中，这和其他程序一样。因为init函数后来产生init进程，而它自己又恰好作为进程运行，这样就很容易产生混淆。
因为idle进程已经占据了进程ID号（PID）0，init（当然是init）就被赋值为下一个可用的PID，也就是1（进程ID在第7章中讨论）。内核重复假定PID为1的进程是init，因此这种特性在没有充分地相互作用，也就是没有同步地进行修改的情况下是不能改变的。
20046：调用lock_kernel（对应UP版本17492行，对应SMP版本10174行）执行后续几行，而不会受到其他会受随后工作的影响的内核模块的干扰。内核锁随后在20053行被释放。
20047：调用do_basic_setup（19916行）初始化总线，并随同其他工作产生一些其他内核线程。
20052：内核已完全完成初始化了，因此free_initmem（7620行）可以舍弃内核的.text.init节的函数和.data.init节的数据。所有使用__initfunc标记过的函数和使用__initdata标记过的数据现在都不能使用了，它们曾经获得的内存现在也可能重新用于其他目的了。
20055：如果可能，打开控制台设备，这样init进程就拥有一个控制台，可以向其中写入信息，也可以从其中读取输入信息。实际上init进程除了打印错误信息以外，并不使用控制台，但是如果调用的是shell或者其他需要交互的进程，而不是init，那么就需要一个可以交互的输入源。如果成功执行open，/dev/console就成为init的标准输入源（文件描述符0）。
20059：调用dup打开/dev/console文件描述符两次，这样，init就也使用它供标准输出和标准错误使用（文件描述符1和2）。假设20055行的open成功执行（正常情况），init现在就有三个文件描述符—标准输入、标准输出及标准错误—全都加载在系统控制台之上。
20067：如果内核命令行中给出了到init的直接路径（或者别的可替代的程序），现在就试图执行init。
因为当execve成功执行目标程序时并不返回，只有当前面的所有处理过程都失败时，才能执行相关的表达式。接下来的几行在几个地方查找init，按照可能性由高到低的顺序依次是：首先是/sbin/init，这是init标准的位置；接下来是两个可能的位置，/etc/init和/bin/init。
20072：这些是init可能出现的所有地方。如果现在还没有出现，init就无法找到它的这个同名者了，机器可能就崩溃了。因此，它就会试图建立一个交互的shell（/bin/sh）来代替。现在init最后的希望就是root用户可以修复这种错误并重新启动机器（可以肯定，root也正是希望如此）。
20073：init甚至不能创建shell—一定是发生了什么问题！按照它们所说的，当所有其他情况都失败时，调用panic（25563行）。这样内核就会试图同步磁盘，确保其状态一致，然后暂停进程的执行。如果超过了内核选项中定义的时间，它也可能会重新启动机器。