Linux内核源代码分析-第四章 系统初始化-2

4.2 初始化Linux内核
在内核成功装入内存（如果需要就解压缩）以及一些关键硬件，例如已经在低层设置过的
内存管理器（MMU，请参见第8章）之后，内核将跳转到start_kernel（19802行）。这个
函数完成其余的系统初始化工作—实际上，几乎所有的初始化工作都是由这个函数实现的
。因此，start_kernel就是本节的核心。
start_kernel
19802：__init标示符在gcc编译器中指定将该函数置于内核的特定区域。在内核完成自身
初始化之后，就试图释放这个特定区域。实际上，内核中存在两个这样的区域，
.text.init和.data.init—第一个是代码初始化使用的，另外一个是数据初始化使用的（
可以在进程间共享的代码和字符串常量之类的“文本（Text）”是在可执行程序中的“纯
区域”中使用的一个术语）。另外你也可以看到__initfunc和__initdata标志，前者和
__init类似，标志初始化专用代码，后者则标志初始化专用数据。
19807：如前所述，即使在多处理器系统中，在启动时也只使用一个CPU。Intel称之为引
导程序处理器（bootstrap processor，简称为BSP），它在内核代码的某些地方有时也称
之为BP。BSP首次运行这一行时，跳过后面的if语句，并减小boot_cpu标志，从而当其他
CPU运行到此处时，都要运行if语句。等到其他CPU被激活执行到这里时，BSP已经在idle
循环中了（本章稍后会更详细地讨论这个问题），initialize_secondary（4355行）负责
把其他CPU加入到BSP中。这样，其他CPU就不用执行start_kernel的剩余部分了—这也是
一件好事，因为这意味着不用再对许多硬件进行冗余初始化等工作了。
顺便说一下，这种奇异的小小的改动只有对于x86是必需的；对于其他平台，调用
smp_init完全可以处理SMP设置的其他部分。因此，其他平台的initialize_secondary的
定义都是空的。
19816：打印内核标题信息（20099行），这里显示了有关内核如何编译的信息，包括在什
么机器上编译，什么时间编译，使用什么版本的编译器，等等。如果中间任何一步发生了
错误，在寻找机器不能启动的原因时查明内核的来源是一个有用的线索。
19817：初始化内核自身的部分组件—内存、硬件中断、调度程序，等等。尤其是
setup_arch函数（19765行）完成体系结构相关的设置，此后在command_line（传递到内
核的参数，在下面讨论）、memory_start和memory_end（内核可用物理地址范围）中返回
结果。下面这些函数都希望驻留在内存低端，它们使用memory_start和memory_end来传递
该信息。在函数获得所希望的值后，返回值指明了新的memory_start的值。
19823：分析传给内核的各种选项。parse_options函数（19707行，在随后的“分析内核
选项”一节中讨论）也设置了argv和envp的初值。
19833：内核运行过程中也可以自行对所进行的工作进行记录，周期性地对所执行的指令
进行抽样，并使用所获得的结果更新表格。这在定时器中断过程中通过调用
x86_do_profile（1896行）来实现，该部分将在第6章中介绍。
如图4-1中说明的那样，这个表格把内核划分为几个大小相同的范围，并简单跟踪在一次
中断的时间内每个范围中运行多少条指令。这种记录当然是非常粗糙的—甚至不是依据函
数和行号进行划分的，而只是使用近似的地址—但是这样代价很低，且快速、短小，而且
有助于专家判断最关键的问题。每个表格条目所涉及到地址的多少—还有问题发生地点的
不确定性—可以通过简单修改prof_shift（26142行）来调节。profile_setup（19076行
，在本章中后面讨论）可以让你在启动的时候设置prof_shift的值，这样比为修改这个数
字而重新编译内核要清晰方便得多。
图4-1 描述用缓存
这个if程序块为记录表格分配内存，并把所有项都清零。注意到如果prof_shift是0（默
认值），那么记录功能就被关掉了，if程序块不再被执行，也不为表格分配空间。
19846：内核通过调用sti（UP版本的13104行，注意该主题在第6章中有更详细的介绍）开
始接收硬件中断。首先需要激活定时器中断，以便后来对calibrate_delay（19654行）的
调用可以计算机器的BogoMIPS的值（在下一节“BogoMIPS”中介绍）。因为一些设备驱动
程序需要BogoMIPS的值，所以内核必需在大部分硬件、文件系统等等初始化之前计算出这
个值来。
19876：测试该CPU的各种缺陷，比如Pentium F00F缺陷（请参见第8章），记录检测到的
缺陷，以便于内核的其他部分以后可以使用它们工作。（为了节省空间起见，我们省略掉
了check_bugs函数。）
19882：调用smp_init（19787行），它又调用了其他的函数来激活SMP系统中的其他CPU：
在x86的平台上，smp_boot_cpus（4614行）初始化一些内核数据结构，这些数据结构跟踪
检测另外的CPU并简单的将其改为保持模式；最后smp_commence（4195行）使这些CPU继续
执行。
19883：把init函数作为内核线程终止，这比较复杂；请参阅本章后面有关init的讨论。

19885：增加idle进程的need_resched标志，这样做的原因此时可能还比较模糊。当读完
了第5、6、7章以后，就会有个清楚的概念；但是，在下一个定时器中断结束之前（在第6
章中讨论），system_call（171行，在第5章中讨论）函数中会注意到idle进程的
need_resched标志增加了，并且调用schedule（26686行，第7章）释放CPU，并将其赋给
更应该获取CPU的进程。
19886：已经完成了内核初始化的工作—或者不管怎样，已经把需要完成的少量责任传递
给了init，所剩余的工作不过是进入idle循环以消耗空闲的CPU时间片。因此，本行调用
cpu_idle（2014行）—idle循环。正如你可以从cpu_idle本身可以发现的一样，该函数从
不返回。然而，当有实际工作要处理时，该函数就会被抢占。
注意到cpu_idle只是反复调用idle系统调用（下一章将讨论系统调用），它通过sys_idle
（2064行）实现真正的idle循环—2014行对应UP版本，2044行针对SMP版本。它们通过执
行hlt（对应“halt”）指令把CPU转入低功耗的“睡眠”状态。只要没有实际的工作处理
，CPU都将转入这种状态。
4.2.1 BogoMIPS
BogoMIPS的数字由内核计算并在系统初始化的时候打印。它近似给出了每秒钟CPU可以执
行一个短延迟循环的次数。在内核中，这个结果主要用于需要等待非常短周期的设备驱动
程序—例如，等待几微秒并查看设备的某些信息是否已经可用。
由于没有正确理解BogoMIPS的含义，BogoMIPS在各处都被滥用，就仿佛它可以满足人类最
原始、最深层次的需求：把所有计算机性能的信息简化为一个数字。“BogoMIPS”中的“
Bogo”部分来源于“伪（bogus）”，就正是为了防止这种用法：虽然这个数字比大多数
基准测试数大，但是它仍然是不准确的、容易引起误解的、无用的和不真实的，根本不适
合将它用于机器间差别的对比。但是这个数字仍然非常吸引人，这也正是我们在这里讨论
这个问题的原因。（BogoMIPS 中“MIPS”部分是“millions of instructions per
second（百万条指令每秒）”的缩写，这是cpu基准测试中的一个常用单位。）
calibrate_delay
19654：calibrate_delay是近似计算BogoMIPS数字的内核函数。
19622：作为第一次估算，calibrate_delay计算出在每一秒内执行多少次__delay循环（
6866行），也就是每个定时器滴答（timer tick）—百分之一秒—内延时循环可以执行多
少次。
19664：计算一个定时器滴答内可以执行多少次循环需要在滴答开始时就开始计数，或者
应该尽可能与它接近。全局变量jiffies（16588行）中存储了从内核开始保持跟踪时间开
始到现在已经经过的定时器滴答数；第6章中将介绍它的实现方式。jiffies保持异步更新
，在一个中断内—每秒一百次，内核暂时挂起正在处理的内容，更新变量，然后继续刚才
的工作。如果不这样处理，下一行的循环就永远不可能退出。从而，如果jiffies不声明
为volatile—简单地说，这个值变化的原因对于编译器是透明的，gcc仍然可能对该循环
进行优化，并引起该循环进入不能退出的状态。虽然目前的gcc还没有如此高的智能，然
而它的维护者应该完全能够为它实现这种智能。
19669：定时器又前移了一个滴答，因此又产生一个新的滴答。下一步是要等待
loops_per_sec延时循环调用定时器循环，接着检测是否最少有一个完整的滴答已经完成
。如果是这样，就退出首次近似估算循环；如果没有，就把loops_per_sec的值加倍，然
后重新启动这个过程。
这个循环的正确性依赖于如下的事实：现有的机器在任何地方都不能每秒执行232次延时
循环（对于64位机来说则远低于每秒264次)，虽然这只是一个微不足道的问题。
19677：现在内核已经清楚loops_per_sec循环调用延时循环在这台机器上要花费超过百分
之一秒的时间才能完成，因此，内核将重新开始进行估算。为了提高效率，内核使用折半
查找算法计算loops_per_sec的实际值，我们假定开始的时候，实际值在现在计算结果和
其一半之间—实际值不可能比现在计算值还大，但是可以（而且可能）稍微小一点。
19681：和前面使用的方式一样，calibrate_delay查看这个loops_per_sec已经减小了的
值是否还是比较大，而需要耗费一个完整的定时器间隔。如果还是相当大，实际值应该小
于当前计算值或者就是当前值，因此，使用更小的值继续查询；如果不够大，就使用一个
更大的值继续查询。
19691：内核有一种很好的方法来计算一个定时器滴答中执行延时循环的次数。这个数字
乘以一秒内滴答的数量就得到了每秒内可以执行的延时循环的次数。这种计算只是一种估
算，乘法也累积了误差，因此结果并不能精确到纳秒。但是这个数字供内核使用已经足够
精确了。
19693：为了让用户感到激动，内核打印出这个数字。注意这里明显省略了%f的格式限定
—内核尽量避免浮点数运算。这个计算过程中最有用的常量是500 000；它是用一百万除
以2得来，理由是每秒钟执行一百万条指令，而每个delay循环的核心是2条指令（decl和
一条跳转指令）。