Linux内核开发人员在提交代码后如何在本地测试他们的代码?他们是否使用某种单元测试和构建自动化?测试计划?
Linux内核开发人员在提交代码后如何在本地测试他们的代码? 他们是否使用某种单元测试和构建自动化?
Linux内核开发人员在提交代码后如何在本地测试他们的代码?
他们是否使用某种单元测试和构建自动化?
从传统意义上来说,没有。
例如,Ingo Molnar正在运行以下工作负载:
每次构建失败、引导失败、错误或运行时警告都会被处理。24/7。乘以几个方框,就可以发现很多问题。
测试计划?
不。
可能存在误解,认为有一个中央测试设施,但实际上没有。每个人都做他/她想做的事。
我可以想象他们使用虚拟化来进行快速测试。它可以是诸如QEMU, VirtualBox或Xen之类的东西,以及一些执行配置和自动化测试的脚本。
自动化测试可能是通过尝试许多随机配置或少数特定配置(如果他们处理特定问题)来完成的。Linux有很多低级工具(比如dmesg命令)来监视和记录来自内核的调试数据,所以我想它也会被使用。
Linux内核非常重视社区测试。
通常情况下,任何开发人员都会在提交代码之前测试他们自己的代码,而且他们经常会使用Linus的内核开发版本,或者其他与他们工作相关的项目的不稳定/开发树之一。这意味着他们经常测试自己的更改和其他人的更改。
通常没有太多正式的测试计划,但是在将特性合并到上游树之前可能会要求进行额外的测试。
正如Dean指出的,还有一些自动化测试,Linux测试项目和内核autotest (良好的概述)。
开发人员通常还会编写针对测试他们的更改的自动化测试,但我不确定是否有一种(经常使用的)机制来集中收集这些临时测试。
当然,这在很大程度上取决于内核的哪个部分正在被更改——您为一个新的网络驱动程序所做的测试与替换核心调度算法时所做的测试是完全不同的。
自动化内核测试并不容易。大多数Linux开发人员自己进行测试,就像adobriyan提到一样。
然而,有一些事情可以帮助调试Linux内核:
然后,开发人员通常会让其他人检查他们的补丁。一旦补丁在本地被检查,并且没有干扰其他任何东西,并且补丁被测试与来自Linus的最新内核一起工作而没有破坏任何东西,补丁就会被推送到上游。
这是一个很好的视频详细描述了一个补丁在集成到内核之前所经历的过程。
当然,内核本身及其部分在发布之前要进行测试,但这些测试只覆盖基本功能。有一些测试系统执行Linux内核的测试:
Linux测试项目 (LTP)向开源社区提供测试套件,以验证Linux的可靠性和稳定性。LTP测试套件包含一组用于测试Linux内核和相关特性的工具。
一个完全自动化测试的框架。它主要用于测试Linux内核,但也有许多其他用途,例如在Linux平台下验证新硬件、虚拟化测试和其他一般用户空间程序测试。它是一个基于GPL的开源项目,被许多组织使用和开发,包括谷歌、IBM、Red Hat和许多其他组织。
还有一些主要的GNU/Linux发行公司开发的认证系统。这些系统通常检查完整的GNU/Linux发行版与硬件的兼容性。有由Novell、Red Hat、Oracle、Canonical和谷歌开发的认证系统。
还有一些Linux内核的动态分析系统:
Kmemleak是Linux内核中包含的内存泄漏检测器。它提供了一种检测可能的内核内存泄漏的方法,其方式类似于跟踪垃圾收集器,不同之处在于孤立对象不被释放,而仅通过/ sys /内核/调试/ kmemleak报告。
Kmemcheck捕获动态分配(即使用kmalloc ())的对内存的每一次读写。如果读取之前没有写入的内存地址,则将消息打印到内核日志中。它也是Linux内核的一部分。
故障注入框架(包含在Linux内核中)允许将错误和异常注入到应用程序的逻辑中,以实现更高的系统覆盖率和容错性。
还有:
MMTests,这是用来分析结果的基准测试和脚本的集合。
三一是Linux系统调用模糊测试器。
此外,SourceForge的LTP页面已经相当过时,项目已经转移到GitHub。
除了其他答案外,本文更强调Linux内核的功能测试、硬件认证测试和性能测试。
大量的测试实际上是通过脚本、静态代码分析工具、代码审查等进行的,这对于捕获错误非常有效,否则会破坏应用程序中的某些东西。
稀疏的 -一个开源工具,用于发现Linux内核中的错误。
Coccinelle是另一个做匹配和转换引擎的程序,它提供了语言SmPL(语义补丁语言),用于在C代码中指定所需的匹配和转换。
pl和其他脚本 -编码风格的问题可以在内核源代码树中的文件文档/ CodingStyle中找到。阅读时要记住的重要事情不是这种风格比其他任何风格都好,而是它是一致的。这可以帮助开发人员轻松地发现和修复编码风格问题。内核源代码树中的脚本脚本/ checkpatch.pl已为其开发。这个脚本可以很容易地指出问题,并且应该总是由开发人员在更改时运行,而不是让审查人员在稍后指出问题上浪费时间。
在树的工具
在内核中找到测试工具的一个好方法是:
make help
在4.0版本中,这导致我:
kselftest under tools/testing/selftests。使用make kselftest运行。必须运行已构建的内核。另见:Documentation/kselftest.txt, https://kselftest.wiki.kernel.org/
make kselftest
ktest under tools/testing/ktest。另见:http://elinux.org/Ktest, http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest
make help的静态分析器部分,其中包含如下目标:
checkstack
coccicheck
内核CI
https://kernelci.org/是一个旨在使内核测试更加自动化和可见的项目。
它似乎只做构建和引导测试(TODO如何自动测试引导工作源应该在https://github.com/kernelci/)。
Linaro似乎是项目的主要维护者,有许多大公司的贡献
Linaro熔岩
http://www.linaro.org/initiatives/lava/看起来像一个专注于开发板和Linux内核的CI系统。
手臂丽莎
https://github.com/ARM-software/lisa
不知道它具体做了什么,但它是由ARM和Apache授权的,所以可能值得一看。
演示:https://www.youtube.com/watch?v=yXZzzUEngiU
一步调试器
不是真正的单元测试,但在测试开始失败时可能会有所帮助:
我自己的QEMU + Buildroot + Python设置
我还开始了一个专注于易于开发的设置,但我最终也添加了一些简单的测试功能:https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b3141724#test-this-repo
我没有非常详细地分析所有其他设置,它们可能比我的设置做得更多,但是我相信我的设置非常容易快速开始,因为它有很多文档和自动化。
LTP和memtest通常是首选工具。
Ingo的循环随机配置构建测试。现在,零日测试机器人(又名kbuild测试机器人)几乎涵盖了这一点。这里提供了一篇关于基础设施的好文章:内核构建/引导测试
这种设置背后的想法是尽快通知开发人员,以便他们能够尽快纠正错误(在某些情况下,在补丁进入Linus的树之前,因为kbuild基础设施也会针对维护人员的子系统树进行测试)。
我已经完成了Linux内核编译,并为Android做了一些修改 (Android 6.0(棉花糖)和Android 7.0(牛轧糖)),其中我使用的是Linux版本3。我在Linux系统上交叉编译它,手动调试错误,然后在Android上运行它的引导映像文件,检查它是否进入了一个漏洞。如果它运行完美,则意味着它根据系统需求进行了完美的编译。
For MotoG内核编译
<强>注意:< / >强 Linux内核将根据依赖于系统硬件的需求进行更改
据我所知,英特尔有一个自动性能回归检查工具(名为lkp/0 day)运行/资助。它将测试发送到邮件列表的每个有效补丁,并检查从不同的微基准测试(如hackbench, fio, unixbench, netperf等)更改的分数。
一旦出现性能下降/改进,相应的报告将直接发送给补丁作者和Cc相关的维护者。
一旦贡献者提交了他们的补丁文件并发出了合并请求,Linux看门人就会通过集成和审查补丁来检查补丁。一旦成功,他们将把补丁合并到相关的分支中,并发布一个新版本。
Linux测试项目是主要的源代码,它提供了在应用补丁后针对内核运行的测试场景(测试用例)。这可能需要大约2 ~ 4个小时,这取决于情况。
请注意关于选择内核将要测试的文件系统。 例如:ext4对ext3产生不同的结果,等等
内核测试过程。