操作系统源代码详细分析三覆盖

水产柜台前人头攒动。一位老妈妈弯着腰细挑慢拣着海蜇丝 3.2 内核体系结构初识 图是一种类Unix操作系统的相当标准的视图，实际上，更细致地说，该图能够说明所有期望具有平台无关特性的操作系统。它着重强调了内核的两个特性： * 内核将应用程序和硬件分离开来。 * 部分内核是体系结构和硬件特有的，而部分内核则是可移植的。 第一点我们在前面章节中已经讨论清楚了，在这里没有必要重复说明。第二点，也就是与体系结构无关和与体系结构相关代码的内容对于我们的讨论比较有意义。内核通过使用与处理用户应用程序相同的技巧来实现部分可移植性。这也就是说，如同内核把用户应用程序和硬件分离一样，部分内核将会因为与硬件的联系而同其他内核分离开来。通过这种分离，用户应用程序和部分内核都成为可移植的。 虽然这通常并不能够使得内核本身更清楚，但是源程序代码的体系结构无关部分通常定义了与低层，也就是体系结构相关部分（或假定）的接口。作为一个简单的例子，内存管理代码中的体系结构无关部分假定只要包含特定的头文件就可以获得合适的PAGE_SIZE 宏（参见10791行）的定义，该宏定义了系统的内存管理硬件用于分割系统地址空间的内存块的大小（参见第8章）。体系结构无关代码并不关心宏的确切定义，而把这些问题都留给体系结构相关代码去处理（顺便一提，这比到处使用#ifdef/#endif程序块来定义平台相关代码要清晰易懂得多）。 这样，内核向新的体系结构的移植就转变成为确认这些特性及在新内核上实现它们的问题。 另外，用户应用程序的可移植性还可以通过它和内核的中间层次—标准C库（libc）—的协助来实现。应用程序实际上从不和内核直接通讯，而只通过libc来实现。图中显示应用程序和内核直接通讯的唯一原因在于它们能够和内核通讯。虽然在实际上应用程序并不同内核直接通讯—这样做是毫无意义的。通过直接和内核通讯所能处理的问题都可以通过使用libc实现，而且更容易。 libc和内核通讯的方式是体系结构相关的（这和图中有一点矛盾），libc负责将用户代码从实现细节中解放出来。有趣的是，甚至大部分libc都不了解这些细节。大部分的libc，例如atoi和rand的实现，都根本不需要和内核进行通讯。剩余的大部分libc，例如printf函数，在涉及到内核之前或之后就已经处理了大量的工作（printf必需首先解释格式化字符串，分析相应参数，设定打印方法，在临时内部缓冲器中记录预期输出。直到此时它才调用底层系统，调用write来实际打印该缓冲区）。其他部分的libc 则只是相应系统调用的简单代理。因而一旦发生函数调用时，它们会立即调用内核相应函数以完成主要工作。在最低层次上，大部分libc通过单通道同内核进行交流，而它们所使用的机制将在第5章进行详细介绍。 由于这种设计，所有的用户应用程序，甚至大部分的C库，都是通过体系结构无关的方式和内核通讯的。 3.3 内核体系结构的深入了解 图显示了内核概念化的一种可能方式。该图和区分内核的体系结构无关及体系结构相关的方法有所不同，它是一种更具有普遍性的结构视图。在“Kernel”框内的本书中有所涉及的内核部分都用括号注明了相应的章节编号。虽然有关对称多处理（SMP）的支持也属于本书的范围，但是在这里我们却没有标明章号。部分原因在于相当多的SMP代码广泛地分布于整个内核中，因此很难将它与某一个模块联系起来。同样，对于内核初始化的支持也属于本书的范围，但是也没有标明章号。这样做是因为从设计的观点上看，该问题并不重要。最后，虽然在图中我们将第6章和“进程间通讯”框联系在一起，但是该章只涉及一部分进程间通讯的内容。 进程和内核的交互通常需要通过如下步骤： 1) 用户应用程序调用系统调用，通常是使用libc。 2) 该调用被内核的system_call函数截获（第5章，171行），此后该函数会将调用请求转发给另外的执行请求的内核函数。 3) 该函数随即和相关内部代码模块建立通讯，而这些模块还可能需要和其他的代码模块或者底层硬件通讯。 4) 结果按照同样的路径依次返回。 然而，并不是所有内核和进程间的交互都是由进程发起的。内核有时也会自行决定同哪个进程交互，例如通过释放信号或者简单的采用直接杀死进程的方法终止该进程的执行（如当进程用完所有可用的CPU时间片），以便使其他进程有机会运行。这些交互过程在该图中并没有表示，主要是因为它们通常都只是内核对自己的内部数据结构的修改（信号传递对于这种规则来说是一个例外）。