Linux内核源代码分析-第二章 代码初识-5

2.3 配置与编译内核
你可能仅仅研读、欣赏而并不修改Linux内核源代码。但是，更普遍的情况是，用户有强
烈的愿望去改进内核代码并完成相应的测试，这样我们就需要知道如何重建内核。本节就
是要告诉你如何实现这一点，而最终则归结于如何把你所做的修改发行给别人，以使得每
个人都能从你的工作中受益。
2.3.1 配置内核
编译内核的第一步就是配置内核，这是增加或者减少对内核特性的支持及修改内核的一些
特性的必要步骤。例如，你可以要求内核为自己的声卡指定一个不同的DMA通道。如果内
核配置和你的需要相同，那么你可以直接跳过本节，否则请继续阅读以下内容。
为了完成内核的配置，请先切换到root用户，然后转入如下内核源程序目录：
cd /usr/src/linux
接着敲入如下命令组：
make config
make menuconfig
make xconfig
这三条命令都可以用来配置内核，但它们发挥作用的方式各不相同：
* make config—三种方法中最简单也是最枯燥的一种。但是最基本的一点是，它可以适
应任何情况。通过为每一个内核支持的特性向用户提问的方式来决定在内核中需要包含哪
些特性。对于大多数问题，你只要回答y（yes，把该特性编译进内核中）、m（作为模块
编译）或者n（no，根本不对该特性提供支持）。在决定之前用户应该考虑清楚，因为这
个过程是不可逆的。如果你在该过程中犯了错误，就只能按Ctrl+C退出。你也可以敲入?
以获取帮助。图2-1显示了这种方法在X终端上运行的情况。
图2-1 运行中的make config
幸运的是，这种方法还有一些智能。例如，如果你对SCSI支持回答no，那么系统就不会再
询问你有关SCSI的细节问题了。而且你可以只按回车键以接受默认的选择，也就是当前的
设置（因此，如果当前内核将对于SCSI的支持编译进了内核，在这个问题上按回车键就意
味着继续把对SCSI的支持编译进内核中）。即使是这样，大部分用户还是宁愿使用另外的
两种方法。
* make menuconfig—一种基于终端的配置机制，用户拥有通过移动光标来进行浏览等功
能。图2-2显示了在X终端上运行的make menuconfig。虽然在控制台上显示的是彩色，但
是在终端上的显示仍然相当单调。使用menuconfig必须要有相应的ncurses类库。
图2-2 运行中的make menuconfig
* make xconfig—这是我最喜欢的一种配置方式。只有你能够在X server上用root用户身
份运行X应用程序时，这种配置方式才可以使用（有些偏执的用户就不愿意使用这种方式
）。你还必须拥有Tcl窗口系统，这实际上还意味着你必须拥有Tcl、Tk以及一个正在运行
的X安装程序。作为补偿，用户获得的是更漂亮的、基于X系统的以及和menuconfig功能相
同的配置方法。图2-3显示了在这种方法运行过程中打开“可装载模块支持（Loadable
module support）”子窗口的情况。
图2-3 运行中的make xconfig
如上所述，这三种方法都实现了相同的功能：它们都生成在构建内核时使用的.config文
件。而唯一的区别在于创建这个文件时的难易程度不同。
2.3.2 构建内核
构建内核要做的工作要比配置内核所做的工作少得多。虽然有几种方式都能实现这一功能
，但是选择哪一种依赖于你希望怎样对系统进行设置。长期以来，我已经形成了如下的习
惯。虽然这种习惯比我所必须要做的略微多一些，但是它包含了所有基本的问题。首先，
如果你还不在内核源程序目录中，请先再次转入这一目录：
cd /usr/src/linux
现在，切换到root用户，使用下面显示的命令生成内核。现在在shell中敲入下面的命令
，注意make命令因为空间关系分成了两行，但实际上这在shell输入时是一个只有一行的
命令：
make dep clean zlilo boot
modules modules_install
当给出了如上多个目标时，除非前面所有的目标都成功了，否则make能够知道没有必要继
续尝试下面的目标。因此，如果make能够运行结束，成功退出，那么这就意味着所有的目
标都正确构建了。现在你可以重新启动机器以运行新的内核。
2.3.3 备份的重要性
当修改（fooling）内核时，你必须准备一个能够启动的备用内核。实现该目的的一种方
式是通过配置Linux加载程序（LILO）以允许用户选择启动的内核映象，其中之一是从没
有修改过的内核的备份（我总是这样做的）。
如果你比较有耐心，那么你就可以使用zdisk目标而不使用zlilo目标；它可以把能够启动
的内核映象写入软盘中。这样你就可以通过在启动时插入软盘的方式启动你的测试内核；
如果没有插入软盘，则启动正常的内核。
但是请注意：内核模块并没有被装载到软盘中，它们实际上是装在硬盘中的（除非你愿意
承担更多的麻烦）。因此，如果你弄乱了内核模块，即使是zdisk目标也救不了你。实际
上，上面提到的这两种方法都存在这个问题。虽然有比较好的解决方法可用，但是最简单
的方法（也就是我所使用的方法）是把备份内核作为严格独立的内核来编译，而不使用可
装载模块的支持。通过这种方法，即使我弄乱了内核而不得不使用备份启动系统，那么不
管问题是实验性内核不正确还是内核模块的原因都无关紧要。不管怎样，在备份的内核中
已经有我需要的所有东西了。
由于用户所做的修改可能导致系统的崩溃，如损坏磁盘上的数据等等，并不仅仅只是打乱
设备驱动程序或文件系统，在测试新内核之前，备份系统的最新数据也是一个英明的决策
（虽然设备驱动程序的开发不是本书的主题，但是必需指出的是，设备驱动程序的缺陷可
能会引起系统的物理损坏。例如显示器是不能备份的，而且因价格昂贵而不易替换）。作
为一个潜在的内核黑客，你的最佳投资（当然是读过本书以后）是一个磁带驱动器和充足
的磁带。
2.3.4 发布你的改进
下面是有关发布你所做修改的一些基本规则：
* 检查最新发行版本，确保你所处理的不是已经解决了的问题。
* 遵守Linux 内核代码编写的风格。简要的说就是8字符缩进以及K&R括号风格（if，else
，for，while，switch或者do后面同一行中紧跟着开括号）。在内核源程序目录下面的文
档编写和代码风格文件给出了完整的规则，不过我们已经介绍了其中的关键部分。注意本
书中包含的源程序代码为节省空间而进行了大量的重新编辑，在该过程中我可能打破了其
中的一些规则。
* 独立发行相对无关的修改。这样，只想使用你所做的某部分修改的人就可以十分方便地
获得想要的东西，而不用一次检验所有的修改内容。
* 让使用你所做修改的用户清楚他们可以从你的修改中获取什么。同样，你也应该给出这
些问题的可信度。你是15min之前才匆匆完成你的修改，甚至还没有时间对它们进行编译
，还是已经在你和你的朋友的系统中已长期稳定地运行过这个修改？
假设现在你已经准备好发行自己的修改版本了，那么要做的第一步是建立一个说明你所做
的修改的文件。你可以使用diff程序自动创建这个文件。结果或者被称为diffs，或者在
Linux中更普遍的被称为补丁（patch）。
发布的过程十分简单。假设原来没有修改过的源程序代码在linux-2.2.5目录下，而你修
改过的源程序代码在linux-my目录下，那么只要进行如下的简单工作就可以了（只有在链
接不存在的情况下才需要执行ln）：
现在，输出文件my.patch包含了其他用户应用这个修改程序时所需要的一切内容。（警告
：如上所述，两个源程序间的所有差别都会包含在这个补丁文件中。diff不能区分修改部
分之间的关系，所以就把它们都罗列了出来。）如果补丁文件相对较小，你可以使用邮件
直接发往内核邮件列表。如果补丁很大，那么就需要通过FTP或者Web站点发布。这时发给
邮件列表的信件中就只需要包含一个URL。
Linux内核邮件列表的常见问题解答（FAQ）文件位于http://www.ececs.uc.edu/~rreilov
a/ linux/lkmlfaq.html。该FAQ中包含了邮件列表的订阅、邮件发布及阅读邮件列表的注
意事项等等。
顺便提一下，如果你想随时了解内核更新开发的进程，向你推荐下面这个具有很高价值的
内核交流站点：http://www.kt.opensrc.org。