Linux内核开发人员如何在本地测试代码并在提交代码之后对其进行测试？他们是否使用某种单元测试，构建自动化？测试计划？
我已经完成了Linux内核编译并为android（Marshmallow和Nougat）做了一些修改，其中我使用的是linux版本3.我在linux系统中交叉编译它，手动调试错误然后在Android中运行其启动映像文件并检查是否它是否进入了环洞 . 如果运行完美则意味着它可以根据系统要求进行完美编译 .For MotoG kernel Compilation
NOTE:- Linux内核将根据依赖于系统硬件的要求进行更改
还有：
MMTests 这是用于分析结果的基准和脚本的集合
https://github.com/gormanm/mmtests
Trinity 这是Linux系统调用模糊测试器
http://codemonkey.org.uk/projects/trinity/
sourceforge上的 LTP 页面已经过时，项目已移至GitHub https://github.com/linux-test-project/ltp
adobriyan提到了Ingo的随机配置构建测试循环 . 现在几乎涵盖了0天测试机器人（又名kbuild测试机器人） . 这里有一篇关于基础设施的好文章：Kernel Build/boot testing
这种设置背后的想法是尽快通知开发人员，以便他们能够尽快纠正错误 . （在某些情况下补丁进入Linus'树之前，因为kbuild基础结构也会对维护者的子系统树进行测试）
LTP和Memtests通常是首选工具 .
除了上/下点之外，还强调了Linux内核的功能测试，硬件认证测试和性能测试 .
实际上通过脚本，静态代码分析工具，代码审查等进行了大量的测试，这在捕获错误方面非常有效，否则会破坏应用程序中的某些内容 .
Sparse - 一个用于查找Linux内核故障的开源工具 .
Coccinelle是另一个程序匹配和转换引擎，它提供语言SmPL（语义补丁语言），用于指定C代码中所需的匹配和转换 .
checkpatch.pl and other scripts - 编码样式问题可以在内核源代码树的Documentation / CodingStyle文件中找到 . 阅读它时要记住的重要事情并不是这种风格在某种程度上比任何其他风格更好，只是它是一致的 . 这有助于开发人员轻松查找和修复编码样式问题，内核源代码树中的脚本scripts / checkpatch.pl已经开发完成 . 此脚本可以轻松指出问题，并且应始终由开发人员对其更改进行操作，而不是让审阅者稍后通过指出问题来浪费时间 .
In-tree tools
在内核中查找测试工具的好方法是：
make help 并阅读所有目标
make help
看下tools/testing
在v4.0中，这导致我：
259 kselftest 在tools/testing/selftests下 . 使用 make kselftest 运行 . 必须已经运行构建的内核 . 另见：Documentation/kselftest.txt，https://kselftest.wiki.kernel.org/
make kselftest
Static analysers 的_249_ Static analysers 部分，其中包含以下目标：
checkstack ：Perl: what does checkstack.pl in linux source do?
checkstack
coccicheck for Coccinelle（提及by askb）
coccicheck
Kernel CI
https://kernelci.org/是一个旨在使内核测试更加自动化和可见的项目 .
它似乎只进行构建和启动测试（TODO如何自动测试启动工作源应该在https://github.com/kernelci/） .
Linaro似乎是该项目的主要维护者，有许多大公司的贡献：https://kernelci.org/sponsors/
Linaro Lava
http://www.linaro.org/initiatives/lava/看起来像一个CI系统，专注于开发板启动和Linux内核 .
ARM LISA
https://github.com/ARM-software/lisa
不确定它的功能是什么，但它是由ARM和Apache Licensed提供的，所以很值得一看 .
演示：https://www.youtube.com/watch?v=yXZzzUEngiU
Step debuggers
不是单元测试，但一旦测试开始失败可能会有所帮助：
QEMU GDB：https://stackoverflow.com/a/42316607/895245
KGDB：https://stackoverflow.com/a/44226360/895245
据我所知，有一个由英特尔运行/资助的自动性能回归检查工具（名为lkp / 0天），它将测试发送到邮件列表的每个有效补丁，并检查从不同的微基准测试（如hackbench）更改的分数，fio，unixbench，netperf等，一旦有性能回归/改进，相应的报告将直接发送给补丁作者和Cc相关的维护者 .
当然，内核本身及其部件在发布之前进行了测试，但这些测试仅涵盖基本功能 . 有一些测试系统可以执行Linux内核的测试：
The Linux Test Project (LTP) 为开源社区提供测试套件，以验证Linux的可靠性和稳定性 . LTP测试套件包含一系列用于测试Linux内核和相关功能的工具 . https://github.com/linux-test-project/ltp
Autotest - 全自动测试的框架 . 它主要用于测试Linux内核，但它可用于许多其他目的，例如在Linux平台下验证新硬件，虚拟化测试和其他一般用户空间程序测试 . 它是GPL下的一个开源项目，由许多组织使用和开发，包括Google，IBM，Red Hat和许多其他组织 . http://autotest.github.io/
还有一些主要的GNU / Linux发行公司开发的认证系统 . 这些系统通常检查完整的GNU / Linux发行版以与硬件兼容 . 那里是由 Novell, Red Hat, Oracle, Canonical, Google 开发的认证系统 .
还有用于Linux内核动态分析的系统：
Kmemleak 是Linux内核中包含的内存泄漏检测程序 . 它提供了一种以类似于跟踪垃圾收集器的方式检测可能的内核内存泄漏的方法，区别在于孤立对象未被释放但仅通过/ sys / kernel / debug / kmemleak报告 .
Kmemcheck 陷阱每次读取和写入动态分配的内存（即使用kmalloc（）） . 如果读取先前未写入的内存地址，则会向内核日志打印一条消息 . 也是Linux Kernel的一部分
Fault Injection Framework （包含在Linux内核中）允许将错误和异常注入应用程序的逻辑中，以实现更高的系统覆盖率和容错能力 .
Linux内核开发人员如何在本地测试代码并在提交后对其进行测试？他们是否使用某种单元测试，构建自动化？
在经典意义上，没有 .
E. g . Ingo Molnar正在运行以下工作负载：1 . 使用随机的配置选项构建新内核2.启动它3.转到1
处理每个构建失败，引导失败，BUG或运行时警告 . 24/7 . 乘以几个盒子，可以发现很多问题 .
测试计划？
没有 .
可能存在误解，即存在中央测试设施，没有 . 每个人都做他想做的事 .
它不是很容易自动化内核测试 . 大多数Linux开发人员都自己进行测试，就像adobriyan提到的那样 .
但是，有一些东西可以帮助调试Linux内核：
kexec: 系统调用，允许您将另一个内核放入内存并重新启动而不返回BIOS，如果失败，请重新启动 .
dmesg: 绝对是寻找有关内核启动过程中发生的事情以及它是否有效的信息的地方 .
Kernel Instrumentation: 除了printk 's (and an option called ' CONFIG_PRINTK_TIME'允许您在内核输出内容时看到（达到微秒精度），内核配置允许您打开许多跟踪器，使其能够调试正在发生的事情 .
然后，开发人员通常让其他人审查他们的补丁一旦在本地审查补丁并且看到它们不干扰其他任何东西，并且测试补丁以使用Linus的最新内核而不破坏任何内容，则补丁被推送到上游 .
Edit: Here's a nice video详细说明补丁在集成到内核之前经历的过程 .
linux内核非常重视社区测试 .
通常，任何开发人员都会在提交之前测试他们自己的代码，并且他们经常会使用Linus的内核开发版本，或者其他不稳定/开发树之一用于与他们的工作相关的项目 . 这意味着他们经常测试他们的变化和其他人的变化 .
正式测试计划的方式往往不多，但在将功能合并到上游树之前可能会要求额外的测试 .
正如Dean指出的那样，还有一些自动测试，linux test project和kernel autotest（good overview） .
开发人员通常也会编写旨在测试其更改的自动化测试，但我不确定是否有（经常使用的）机制来集中收集这些特殊测试 .
当然，这取决于内核的哪个区域正在被更改 - 您为新网络驱动程序所做的测试与更换核心调度算法时所做的测试完全不同 .
我想他们会使用虚拟化来进行快速测试，例如QEMU，VirtualBox或Xen，以及一些脚本来执行配置和自动化测试 .
自动化测试可能是通过尝试许多随机配置或一些特定配置（如果他们正在处理特定问题）来完成的 . Linux有很多低级工具（例如dmesg）来监视和记录来自内核的调试数据，所以我想也可以使用它 .
12 回答
我已经完成了Linux内核编译并为android（Marshmallow和Nougat）做了一些修改，其中我使用的是linux版本3.我在linux系统中交叉编译它，手动调试错误然后在Android中运行其启动映像文件并检查是否它是否进入了环洞 . 如果运行完美则意味着它可以根据系统要求进行完美编译 .
For MotoG kernel Compilation
NOTE:- Linux内核将根据依赖于系统硬件的要求进行更改
还有：
MMTests 这是用于分析结果的基准和脚本的集合
https://github.com/gormanm/mmtests
Trinity 这是Linux系统调用模糊测试器
http://codemonkey.org.uk/projects/trinity/
sourceforge上的 LTP 页面已经过时，项目已移至GitHub https://github.com/linux-test-project/ltp
adobriyan提到了Ingo的随机配置构建测试循环 . 现在几乎涵盖了0天测试机器人（又名kbuild测试机器人） . 这里有一篇关于基础设施的好文章：Kernel Build/boot testing
这种设置背后的想法是尽快通知开发人员，以便他们能够尽快纠正错误 . （在某些情况下补丁进入Linus'树之前，因为kbuild基础结构也会对维护者的子系统树进行测试）
LTP和Memtests通常是首选工具 .
除了上/下点之外，还强调了Linux内核的功能测试，硬件认证测试和性能测试 .
实际上通过脚本，静态代码分析工具，代码审查等进行了大量的测试，这在捕获错误方面非常有效，否则会破坏应用程序中的某些内容 .
Sparse - 一个用于查找Linux内核故障的开源工具 .
Coccinelle是另一个程序匹配和转换引擎，它提供语言SmPL（语义补丁语言），用于指定C代码中所需的匹配和转换 .
checkpatch.pl and other scripts - 编码样式问题可以在内核源代码树的Documentation / CodingStyle文件中找到 . 阅读它时要记住的重要事情并不是这种风格在某种程度上比任何其他风格更好，只是它是一致的 . 这有助于开发人员轻松查找和修复编码样式问题，内核源代码树中的脚本scripts / checkpatch.pl已经开发完成 . 此脚本可以轻松指出问题，并且应始终由开发人员对其更改进行操作，而不是让审阅者稍后通过指出问题来浪费时间 .
In-tree tools
在内核中查找测试工具的好方法是：
make help并阅读所有目标看下tools/testing
在v4.0中，这导致我：
259 kselftest 在tools/testing/selftests下 . 使用
make kselftest运行 . 必须已经运行构建的内核 . 另见：Documentation/kselftest.txt，https://kselftest.wiki.kernel.org/Static analysers 的_249_ Static analysers 部分，其中包含以下目标：
checkstack：Perl: what does checkstack.pl in linux source do?coccicheckfor Coccinelle（提及by askb）Kernel CI
https://kernelci.org/是一个旨在使内核测试更加自动化和可见的项目 .
它似乎只进行构建和启动测试（TODO如何自动测试启动工作源应该在https://github.com/kernelci/） .
Linaro似乎是该项目的主要维护者，有许多大公司的贡献：https://kernelci.org/sponsors/
Linaro Lava
http://www.linaro.org/initiatives/lava/看起来像一个CI系统，专注于开发板启动和Linux内核 .
ARM LISA
https://github.com/ARM-software/lisa
不确定它的功能是什么，但它是由ARM和Apache Licensed提供的，所以很值得一看 .
演示：https://www.youtube.com/watch?v=yXZzzUEngiU
Step debuggers
不是单元测试，但一旦测试开始失败可能会有所帮助：
QEMU GDB：https://stackoverflow.com/a/42316607/895245
KGDB：https://stackoverflow.com/a/44226360/895245
据我所知，有一个由英特尔运行/资助的自动性能回归检查工具（名为lkp / 0天），它将测试发送到邮件列表的每个有效补丁，并检查从不同的微基准测试（如hackbench）更改的分数，fio，unixbench，netperf等，一旦有性能回归/改进，相应的报告将直接发送给补丁作者和Cc相关的维护者 .
当然，内核本身及其部件在发布之前进行了测试，但这些测试仅涵盖基本功能 . 有一些测试系统可以执行Linux内核的测试：
The Linux Test Project (LTP) 为开源社区提供测试套件，以验证Linux的可靠性和稳定性 . LTP测试套件包含一系列用于测试Linux内核和相关功能的工具 . https://github.com/linux-test-project/ltp
Autotest - 全自动测试的框架 . 它主要用于测试Linux内核，但它可用于许多其他目的，例如在Linux平台下验证新硬件，虚拟化测试和其他一般用户空间程序测试 . 它是GPL下的一个开源项目，由许多组织使用和开发，包括Google，IBM，Red Hat和许多其他组织 . http://autotest.github.io/
还有一些主要的GNU / Linux发行公司开发的认证系统 . 这些系统通常检查完整的GNU / Linux发行版以与硬件兼容 . 那里是由 Novell, Red Hat, Oracle, Canonical, Google 开发的认证系统 .
还有用于Linux内核动态分析的系统：
Kmemleak 是Linux内核中包含的内存泄漏检测程序 . 它提供了一种以类似于跟踪垃圾收集器的方式检测可能的内核内存泄漏的方法，区别在于孤立对象未被释放但仅通过/ sys / kernel / debug / kmemleak报告 .
Kmemcheck 陷阱每次读取和写入动态分配的内存（即使用kmalloc（）） . 如果读取先前未写入的内存地址，则会向内核日志打印一条消息 . 也是Linux Kernel的一部分
Fault Injection Framework （包含在Linux内核中）允许将错误和异常注入应用程序的逻辑中，以实现更高的系统覆盖率和容错能力 .
在经典意义上，没有 .
E. g . Ingo Molnar正在运行以下工作负载：1 . 使用随机的配置选项构建新内核2.启动它3.转到1
处理每个构建失败，引导失败，BUG或运行时警告 . 24/7 . 乘以几个盒子，可以发现很多问题 .
没有 .
可能存在误解，即存在中央测试设施，没有 . 每个人都做他想做的事 .
它不是很容易自动化内核测试 . 大多数Linux开发人员都自己进行测试，就像adobriyan提到的那样 .
但是，有一些东西可以帮助调试Linux内核：
kexec: 系统调用，允许您将另一个内核放入内存并重新启动而不返回BIOS，如果失败，请重新启动 .
dmesg: 绝对是寻找有关内核启动过程中发生的事情以及它是否有效的信息的地方 .
Kernel Instrumentation: 除了printk 's (and an option called ' CONFIG_PRINTK_TIME'允许您在内核输出内容时看到（达到微秒精度），内核配置允许您打开许多跟踪器，使其能够调试正在发生的事情 .
然后，开发人员通常让其他人审查他们的补丁一旦在本地审查补丁并且看到它们不干扰其他任何东西，并且测试补丁以使用Linus的最新内核而不破坏任何内容，则补丁被推送到上游 .
Edit: Here's a nice video详细说明补丁在集成到内核之前经历的过程 .
linux内核非常重视社区测试 .
通常，任何开发人员都会在提交之前测试他们自己的代码，并且他们经常会使用Linus的内核开发版本，或者其他不稳定/开发树之一用于与他们的工作相关的项目 . 这意味着他们经常测试他们的变化和其他人的变化 .
正式测试计划的方式往往不多，但在将功能合并到上游树之前可能会要求额外的测试 .
正如Dean指出的那样，还有一些自动测试，linux test project和kernel autotest（good overview） .
开发人员通常也会编写旨在测试其更改的自动化测试，但我不确定是否有（经常使用的）机制来集中收集这些特殊测试 .
当然，这取决于内核的哪个区域正在被更改 - 您为新网络驱动程序所做的测试与更换核心调度算法时所做的测试完全不同 .
我想他们会使用虚拟化来进行快速测试，例如QEMU，VirtualBox或Xen，以及一些脚本来执行配置和自动化测试 .
自动化测试可能是通过尝试许多随机配置或一些特定配置（如果他们正在处理特定问题）来完成的 . Linux有很多低级工具（例如dmesg）来监视和记录来自内核的调试数据，所以我想也可以使用它 .