Linux内核开发人员在提交代码后如何在本地测试他们的代码?他们是否使用某种单元测试和构建自动化?测试计划?


当前回答

Linux内核开发人员在提交代码后如何在本地测试他们的代码? 他们是否使用某种单元测试和构建自动化?

从传统意义上来说,没有。

例如,Ingo Molnar正在运行以下工作负载:

用一组随机配置选项构建一个新内核 引导进入 转到第1节

每个构建失败、启动失败、错误或运行时警告都将得到处理。24/7。乘以几个方框,就可以发现很多问题。

测试计划?

No.

可能存在误解,认为有一个中央测试设施,但实际上没有。每个人都做他/她想做的事。

其他回答

LTP和memtest通常是首选工具。

Linux内核开发人员在提交代码后如何在本地测试他们的代码? 他们是否使用某种单元测试和构建自动化?

从传统意义上来说,没有。

例如,Ingo Molnar正在运行以下工作负载:

用一组随机配置选项构建一个新内核 引导进入 转到第1节

每个构建失败、启动失败、错误或运行时警告都将得到处理。24/7。乘以几个方框,就可以发现很多问题。

测试计划?

No.

可能存在误解,认为有一个中央测试设施,但实际上没有。每个人都做他/她想做的事。

还有:

MMTests是用来分析结果的基准测试和脚本的集合。

它是Linux系统调用模糊测试器。

此外,SourceForge的LTP页面已经相当过时,项目已经转移到GitHub。

除了其他答案外,本文更强调Linux内核的功能测试、硬件认证测试和性能测试。

大量的测试实际上是通过脚本、静态代码分析工具、代码审查等进行的,这对于捕获错误非常有效,否则会破坏应用程序中的某些东西。

稀疏-一个开源工具,旨在发现Linux内核中的错误。

Coccinelle是另一个程序进行匹配和转换引擎,它提供了语言SmPL(语义补丁语言),用于在C代码中指定所需的匹配和转换。

checkpatch.pl and other scripts - coding style issues can be found in the file Documentation/CodingStyle in the kernel source tree. The important thing to remember when reading it is not that this style is somehow better than any other style, just that it is consistent. This helps developers easily find and fix coding style issues. The script scripts/checkpatch.pl in the kernel source tree has been developed for it. This script can point out problems easily, and should always be run by a developer on their changes, instead of having a reviewer waste their time by pointing out problems later on.

我可以想象他们使用虚拟化来进行快速测试。它可以是QEMU、VirtualBox或Xen之类的东西,以及一些执行配置和自动化测试的脚本。

自动化测试可能是通过尝试许多随机配置或少数特定配置(如果他们处理特定问题)来完成的。Linux有很多低级工具(比如dmesg)来监视和记录来自内核的调试数据,所以我认为也会使用它。