据我所知，英特尔有一个自动性能回归检查工具(名为lkp/0 day)运行/资助。它将测试发送到邮件列表的每个有效补丁，并检查从不同的微基准测试(如hackbench, fio, unixbench, netperf等)更改的分数。

一旦出现性能下降/改进，相应的报告将直接发送给补丁作者和Cc相关的维护者。

自动化内核测试并不容易。大多数Linux开发人员自己进行测试，就像adobriyan提到的那样。

然而，有一些事情可以帮助调试Linux内核:

kexec: A system call that allows you to put another kernel into memory and reboot without going back to the BIOS, and if it fails, reboot back. dmesg: Definitely the place to look for information about what happened during the kernel boot and whether it works/doesn't work. Kernel Instrumentation: In addition to printk's (and an option called 'CONFIG_PRINTK_TIME' which allows you to see (to microsecond accuracy) when the kernel output what), the kernel configuration allows you to turn on a lot of tracers that enable them to debug what is happening.

然后，开发人员通常会让其他人检查他们的补丁。一旦补丁在本地被检查，并且没有干扰其他任何东西，并且补丁被测试与来自Linus的最新内核一起工作而没有破坏任何东西，补丁就会被推送到上游。

这里有一个很好的视频，详细介绍了一个补丁在集成到内核之前所经历的过程。

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

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

一旦贡献者提交了他们的补丁文件并发出了合并请求，Linux看门人就会通过集成和审查补丁来检查补丁。一旦成功，他们将把补丁合并到相关的分支中，并发布一个新版本。

Linux测试项目是提供在应用补丁后针对内核运行的测试场景(测试用例)的主要来源。这可能需要大约2 ~ 4个小时，这取决于情况。

请注意所选内核将要测试的文件系统。 例如:ext4生成的结果与ext3不同，依此类推。

内核测试过程。

从存储库(Linux内核档案或GitHub)获取最新的内核源代码 应用补丁文件(使用diff工具) 构建新内核。 针对LTP (Linux测试项目)中的测试过程进行测试

adobriyan提到了Ingo的随机配置构建测试循环。现在，零日测试机器人(又名kbuild测试机器人)几乎涵盖了这一点。这里有一篇关于基础结构的不错的文章:内核构建/引导测试

这种设置背后的想法是尽快通知开发人员，以便他们能够尽快纠正错误(在某些情况下，在补丁进入Linus的树之前，因为kbuild基础设施也会针对维护人员的子系统树进行测试)。

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

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

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

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

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

测试计划?

No.

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