操作系统源代码详细分析二

因此与他们会面是很重要的。实际上 2.1.2 内核代码习惯用语 内核代码中使用了一些显著的习惯用语，本节将介绍常用的几个。当通读源代码时，真正重要的问题并不在这些习惯用语本身，而是这种类型的习惯用语的确存在，而且是不断被使用和发展的。如果你需要编写内核代码，你应该注意到内核中所使用的习惯用语，并把这些习惯用语应用到你的代码中。当通读本书（或者代码）时，看看你还能找到多少习惯用语。 为了讨论这些习惯用语，我们首先需要对它们进行命名。为了便于讨论，笔者创造了这些名字。而在实际中，大家不一定非要参考这些用语，它们只是对内核工作方式的描述而已。 一个普通的习惯用语，笔者称之为“资源获取”（resource acquisition idiom）。在这个用语中，一个函数必须实现一系列资源的获取，包括内存、锁等等（这些资源的类型未必相同）。只有成功地获取当前所需要的资源之后，才能处理后面的资源请求。最后，该函数还必须释放所有已经获取的资源，而不必考虑没有获取的资源。 我采用“错误变量”这一用语（error variable idiom）来辅助说明资源获取用语，它使用一个临时变量来记录函数的期望返回值。当然，相当多的函数都能实现这个功能。但是错误变量的不同点在于它通常是用来处理由于速度的因素而变得非常复杂的流程控制中的问题。错误变量有两个典型的值，0（表示成功）和负数（表示有错）。 如果执行到标号out2，则都已经获取了r1和r2资源，而且也都需要进行释放。如果执行到标号out1（不管是顺序执行还是使用goto语句进行跳转到），则r2资源是无效的（也可能刚被释放），但是r1资源却是有效的，而且必需在此将其释放。同理，如果标号out能被执行，则r1和r2资源都无效，err所返回的是错误或成功标志。 在这个简单的例子中，对err的一些赋值是没有必要的。在实践中，实际代码必须遵守这种模式。这样做的原因主要在于同一行中可能包含有多种测试，而这些测试应该返回相同的错误代码，因此对错误变量统一赋值要比多次赋值更为简单。虽然在这个例子中对于这种属性的必要性并不非常迫切，但是我还是倾向于保留这种特点。有关的实际应用可以参考sys_shmctl（第21654行），在第9章中还将详细介绍这个例子。 2.1.3 减少#if和#ifdef的使用 现在的Linux内核已经移植到不同的平台上，但是我们还必须解决移植过程中所出现的问题。大部分支持各种不同平台的代码由于包含许多预处理代码而已经变得非常不规范，例如： 这个例子试图实现操作系统的可移植性，虽然Linux关注的焦点很明显是实现代码在各种CPU上的可移植性，但是二者的基本原理是一致的。对于这类问题来说，预处理器是一种错误的解决方式。这些杂乱的问题使得代码晦涩难懂。更为糟糕的是，增加对新平台的支持有可能要求重新遍历这些杂乱分布的低质量代码段（实际上你很难能找到这类代码段的全部）。 与现有方式不同的是，Linux一般通过简单函数（或者是宏）调用来抽象出不同平台间的差异。内核的移植可以通过实现适合于相应平台的函数（或宏）来实现。这样不仅使代码的主体简单易懂，而且在移植的过程中还可以比较容易地自动检测出你没有注意到的内容：如引用未声明函数时会出现链接错误。有时用预处理器来支持不同的体系结构，但这种方式并不常用，而相对于代码风格的变化就更是微不足道了。 顺便说一下，我们可以注意到这种解决方法和使用用户对象（或者C语言中充满函数指针的struct结构）来代替离散的switch语句处理不同类型的方法十分相似。在某些层次上，这些问题和解决方法是统一的。 可移植性的问题并不仅限于平台和CPU的移植，编译器也是一个重要的问题。此处为了简化，假设Linux只使用gcc来编译。由于Linux只使用同一个编译器，所以就没有必要使用#if块（或者#ifdef块）来选择不同的编译器。 内核代码主要使用#ifdef来区分需要编译或不需要编译的部分，从而对不同的结构提供支持。例如，代码经常测试SMP宏是否定义过，从而决定是否支持SMP机。