4.2.代码检查工具¶

至少目前，编写无错误代码仍然是我们中很少人能达到的理想状态。不过，我们希望做

的是，在代码进入主线内核之前，尽可能多地捕获并修复这些错误。为此，内核开发人

员已经组装了一系列令人印象深刻的工具，可以自动捕获各种各样的模糊问题。计算机

发现的任何问题都是一个以后不会困扰用户的问题，因此，只要有可能，就应该使用

自动化工具。

第一步只是注意编译器产生的警告。当代版本的GCC可以检测(并警告)大量潜在错误。

通常，这些警告都指向真正的问题。提交以供审阅的代码通常不会产生任何编译器警告。

在消除警告时，注意了解真正的原因，并尽量避免“修复”，使警告消失而不解决其原因。

请注意，并非所有编译器警告都默认启用。使用“make KCFLAGS=-W”构建内核以

获得完整集合。

内核提供了几个配置选项，可以打开调试功能；大多数配置选项位于“kernel hacking”

子菜单中。对于任何用于开发或测试目的的内核，都应该启用其中几个选项。特别是，

您应该打开：

启用 ENABLE_MUST_CHECK and FRAME_WARN 以获得一组额外的警告，以解决使用不

推荐使用的接口或忽略函数的重要返回值等问题。这些警告生成的输出可能是冗长

的，但您不必担心来自内核其他部分的警告。

DEBUG_OBJECTS 将添加代码，以跟踪内核创建的各种对象的生存期，并在出现问题时

发出警告。如果要添加创建(和导出)自己的复杂对象的子系统，请考虑添加对对象

调试基础结构的支持。

DEBUG_SLAB 可以发现各种内存分配和使用错误；它应该用于大多数开发内核。

DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP and DEBUG_MUTEXES 会发现许多常见的

锁定错误.

还有很多其他调试选项，其中一些将在下面讨论。其中一些具有显著的性能影响，不应

一直使用。但是，在学习可用选项上花费的一些时间可能会在短期内得到多次回报。

其中一个较重的调试工具是锁定检查器或“lockdep”。该工具将跟踪系统中每个锁

(spinlock或mutex)的获取和释放、获取锁的相对顺序、当前中断环境等等。然后，

它可以确保总是以相同的顺序获取锁，相同的中断假设适用于所有情况，等等。换句话

说，lockdep可以找到许多场景，在这些场景中，系统很少会死锁。在部署的系统中，

这种问题可能会很痛苦(对于开发人员和用户而言)；LockDep允许提前以自动方式

发现问题。具有任何类型的非普通锁定的代码在提交包含前应在启用lockdep的情况

下运行。

作为一个勤奋的内核程序员，毫无疑问，您将检查任何可能失败的操作(如内存分配)

的返回状态。然而，事实上，最终的故障恢复路径可能完全没有经过测试。未测试的

代码往往会被破坏；如果所有这些错误处理路径都被执行了几次，那么您可能对代码

更有信心。

内核提供了一个可以做到这一点的错误注入框架，特别是在涉及内存分配的情况下。

启用故障注入后，内存分配的可配置百分比将失败；这些失败可以限制在特定的代码

范围内。在启用了故障注入的情况下运行，程序员可以看到当情况恶化时代码如何响

应。有关如何使用此工具的详细信息，请参阅

Fault injection capabilities infrastructure。

使用“sparse”静态分析工具可以发现其他类型的错误。对于sparse，可以警告程序员

用户空间和内核空间地址之间的混淆、big endian和small endian数量的混合、在需

要一组位标志的地方传递整数值等等。sparse必须单独安装(如果您的分发服务器没

有将其打包，可以在 https://sparse.wiki.kernel.org/index.php/Main_page)找到,

然后可以通过在make命令中添加“C=1”在代码上运行它。

“Coccinelle”工具 http://coccinelle.lip6.fr/

能够发现各种潜在的编码问题；它还可以为这些问题提出修复方案。在

scripts/coccinelle目录下已经打包了相当多的内核“语义补丁”；运行

“make coccicheck”将运行这些语义补丁并报告发现的任何问题。有关详细信息，请参阅

其他类型的可移植性错误最好通过为其他体系结构编译代码来发现。如果没有S/390系统

或Blackfin开发板，您仍然可以执行编译步骤。可以在以下位置找到一组用于x86系统的

大型交叉编译器：

花一些时间安装和使用这些编译器将有助于避免以后的尴尬。