代码质量保证体系——Linux

疫情在肆虐，说心忧天下貌似有些大了，只能先说些小的，在这里尝试描述一下Linux为保证代码质量所做的努力，来完成这个主题的最后一篇，也希望这段不好的日子的最后篇章也早些到来。

编码规范

这一环节涵盖了两个方面的含义：一份行之有效的编码规范，加上一些辅助检查代码是否符合规范的工具。一个项目可以比作一个国家，这个项目采用的编程语言就是这个国家的官方语言，每个开发者使用这门语言在这个国家里表达自己的喜怒哀乐恩怨情仇，那么编码规范就相当于各种法律法规，来适当的对开发者的言行做出一定的约束。

在Linux这个王国里，它的法律条文都在文档Documentation/process/coding-style.rst。我们不用去思考里面的每一条细节为什么会存在，就像很多时候我们也不用去思考为什么故宫博物馆里会有那么一只特立独行在大奔上笑的鸡。比如，在很多编码规范里被排斥嘲笑的goto，就堂而皇之的在Linux内核里随处可见，如果你的代码里隔个多少行不出现个goto，你都不好意思和人打招呼了。

都说人类一思考，上帝就会发笑，没错，Linus就是这个王国的上帝。但是还好，这个上帝为我们提供了一个检查代码是否符合内核编码规范的辅助工具，就是脚本scripts/checkpatch.pl。顾名思义，checkpatch是用来检查patch的，默认的调用也确实如此。如果用来检查C的原文件，需要加上“-f”的选项。

我们经常也会通过下面的一个脚本，添加一个Git pre-commit hook，在提交任何一个commit之前就自动的执行checkpatch去审查我们的代码。

#!/bin/sh## pre-commit hook to run check-patch on the output and stop any commits# that do not pass. Note, only for git-commit, and not for any ofthe# other scenarios## Copyright 2010 Ben Dooks, ben-linux@fluff.org
if gitrev-parse --verify HEAD 2>/dev/null >/dev/nullthen    against=HEADelse    # Initial commit: diff against anempty tree object    against=4b825dc642cb6eb9a060e54bf8d69288fbee4904fi
git diff--cached $against -- | /scripts/checkpatchpl--no-signoff -

代码静态检测

编码规范只能约束开发者表面的行为举止，而针对隐藏人心的那些罪恶，Linus提供了另外一个工具——sparse，没错，sparse就是Linux内核里“游移在法律与罪恶之间的一名清道夫”。

sparse在内核的使用很简单，编译内核代码的时候，使用make C=1或C=2，在Linux内核顶层的Makefile里就会默认调用sparse，从而对内核代码进行检查。

# Call a source code checker (by default, "sparse") as part of the# C compilation.## Use 'make C=1' to enable checking of only re-compiled files.# Use 'make C=2' to enable checking of *all* source files, regardless# of whether they are re-compiled or not.## See the file "Documentation/dev-tools/sparse.rst" for more details,# including where to get the "sparse" utility.

当然，作为sparse的接盘侠，josh后来将sparse从内核推广到了应用程序，至于在user space里的效果，虽然比起coverity这样的专业利器有些辣眼睛，但是帮助还是有的，有兴趣的可以自己尝试。

除了sparse，另外还可以使用工具coccinelle，在那个顶层的Makefile中，定义有目标coccicheck，在scripts目录中从前向后调用coccicheck。对于coccinelle，还可以使用M=来指定处理的目录。

make coccicheckmake coccicheck M=drivers/net/wireless/

单元测试

上一篇提到OpenStack的单元测试时，有说我们提交一些新的代码时，必须要做的事情是往往提交更多的测试代码，而且常常花在单元测试上的时间要更多。这对于整个项目来说自然是好事，但是对于程序员这个貌似“很不好相处”的群体来说，往往是很大的负担。

对于Linux内核没有这种负担，虽然我们的代码在邮件列表里可能会被骂“狗屎”“垃圾”，但是我们并不用写好配套的茫茫多的单元测试代码才能提交patch。

那么内核的代码，所谓的稳定版等又是怎么个保证稳定的？有关这个我们可以去lwn上翻翻这篇文章——Testing kernels，里面说内核主干有可能并没有做过充分的测试，而稳定内核可能会更少……。（https://lwn.net/Articles/734016/）

Anyway，内核还是需要并且有茫茫多的测试、调试、性能分析工具的，这里面，我自己感觉能够往单元测试框架上靠的目前有两个：kselftest与KUnit（kernel unit-testing framework）。kselftest是内置的一组功能测试用例，编译出来的就是一个个独立的可执行程序。KUnit是新近提出的一个测试框架。有关它们的并存也有不少的争议，可以看去年lwn上的另一篇文章——How many kernel test frameworks（https://lwn.net/Articles/790235/）

持续集成

与单元测试的情况类似，Linux内核也并没有OpenStack里Jackins搭建的持续集成服务器来对每个commit进行集成测试。但是有个0-Day kernel test service项目做了类似的事情。

0-Day由大神吴峰光在Intel一手养大，起初就是利用一批淘汰下来的服务器，在实验室搭建了一个测试环境，可以自动的把内核最新的code和每个人提交的commit给同步下来，进行编译测试，也包括一些性能方面的测试，如果检查出问题就会给内核邮件列表发邮件。如果你有在内核邮件列表发patch的经历，应该就会收到过相应的邮件。现在在Intel有专门的一个组在做0-Day/LKP(Linux Kernel Performance)的工作。

代码评审与重构

同样，Linux内核也没有Gerrit这样的平台用于review，内核社区的核心就是mail list，订阅mail list的所有人都是你要为自己commit寻找的“橡皮鸭”，他们基本不会放过你代码里的任何错误，包括逻辑设计的问题。增加一个feature，你的patch不断的重构，反复的推翻重来都是常事，你不用觉得自己会有糊弄过关的侥幸。在里面混下去的核心秘诀就是要脸皮厚，和你追小姑娘是同样的道理。

好一大群可爱的“橡皮鸭”！

相关阅读

代码质量保证体系（上）

代码质量保证体系（下）

代码质量保证体系——OpenStack​​​​​​​

喜欢的话，欢迎扫码关（打）注（赏） ^-^