综合技术

LWN:Linux kernel要有几种test framework?

微信扫一扫,分享到朋友圈

LWN:Linux kernel要有几种test framework?
0

How many kernel test frameworks?

By Jake Edge

June 5, 2019

Linux kernel的自测试框架名为kselftest,已经加入kernel一段时间了。最近又有一个新的kernel unit-testing framework(KUnit)提出来,那么为什么要有两种方案共存呢?关于KUnit有一个邮件讨论话题经过了很长的讨论,大家都在争论为什么要在kernel里增加另一个测试框架。虽然kselftest和KUnit的使用场景并不一样,不过人们还是有些担心两者共存会导致内核测试整体工作的分裂。

5月上旬Brendan Giggins推送了KUnit patch set的第二版,期待能合入Linux 5.2。Greg Kroah-Hartman和 Shuah Khan 觉得这个可能有点时间太紧,毕竟merge window还有1周时间。不过Khan也赞同这组patch应该从她的kselftest tree这边来进入Linux kernel。这组patch里面有一些细节问题还要解决,不过整体来说已经拿到了approval和不少开发者的reviewed-by签字。

不过,Korah-Hartman和Logan Gunthorpe等人都还在抱怨KUnit对user-mode Linux (UML)的依赖。Higgins回复说“基本上解决了”。KUnit现在可以在任何体系架构上运行,不过在UML里面测试的话Python wrapper script还是需要的。他打算仔细写个文档描述清楚(后来他也确实发出来文档了)。

另一个问题是Frank Rowand提出的。从他角度来看,使用UML就意味着“避免在真实硬件或虚拟机里启动kernel”。当然,他也觉得这并不是不可以,毕竟用UML来跑Linux也就是另外一种意义上的虚拟化而已。不过,他更不喜欢的是:

KUnit对我来说就是作为kernel developer必须要去熟悉的另一个框架,带来更多麻烦,也要给我的小脑瓜里面塞更多信息进去。

我猜有些开发者估计只会尽量利用两种框架之一,这样最终会导致开发资源的分裂,还不如把所有人都引向唯一一个测试框架。

Khan的回复中讲,她认为kselftest和KUnit是可以互补的。Kselftest是“一组user-space测试的集合,在部分case里依赖一些kernel test module”。而KUnit就提供了一种in-kernel的测试框架。

不过Rowand没被Khan的说法说服,他觉得两个框架大部分是重复的。

与众不同的是,Ted Ts’o确实有经历证明UML测试会有帮助。他介绍过有一些针对ext4的unit test正在开发过程中,它们会能够对ext4的一些功能在独立于kernel其他部分的环境下进行测试,因此他倒觉得用UML测试会很有帮助。kselftest框架里的测试都是针对user space里运行的测试,这需要先启动一个真实的kernel。而KUnit就很简单,也能很快用起来:

所以,这就是为什么我觉得KUnit用UML不是什么问题。事实上我更觉得这是一个好功能。我们不是在测试设备驱动程序,或者内核调度器,或者任何跟体系架构有关的东西。UML并不是虚拟化。它在这个情景下能让我们尽快运行起测试代码来。启动KVM需要3~4秒时间,还包含初始化virtio_scsi和其他设备驱动。如果用UML,我们可以把其他不相干的kernel子系统尽量裁剪,裁到极致。此外,它也意味着我们能让userspace的"printf"直接跟测试框架交流,而不需要跟KVM的虚拟串口或者虚拟控制台通讯,这样搭建测试环境的花销更加能大大减少了。

Frameworks

大家的意见分歧,可能部分来源于怎么定义framework(框架)。Ts’o坚持认为kselftest提供的不是一个in-kernel的测试框架,而Rowand也强烈反对这个说法。Rowand提出kselftest里面用到了kernel module,并且这些module也是能编译进UML kernel的。Ts’o不认为这个算是framework,毕竟“每个in-kernel的代码段要想测试都需要自己创建自己的in-kernel测试架构”。Rowand不这么看,他觉得:“kselftest的in-kernel测试都是遵循统一规范的,因此这就是一个测试框架”。对Ts’o来说,这算不上是一个框架,他评论说:

我们可能对framework的定义不太一样,在我的理解里,通过cut and paste来进行的代码重用不是一个framework。今后如果把这部分测试重写,真正利用KTF或者KUnit这样的framework,那也可以。不过它们现在并没有用真正的framework。

此外,Ts’o还指出kselftest需要有一个可用的user-space环境:

有一个主要的区别:kselftest需要一个userspace环境,它先启动systemd,依赖一个root file system这样才能加载module,等等等等。而Kunit就不需要root file system,也不需要启动systemd,也不允许你去跑各种perl/python/bash等等脚本。

Rowand仍然不赞成:

Kselftest in-kernel test(我们目前讨论的是这个场景)就可以被编译进kernel,而不是编译成module,也可以编译进UML kernel。这样UML kernel就能启动、然后在UML调用init进程之前就先开始跑in-kernel test。

不需要有userspace环境,因此同KUnit的调用场景比起来开销并不多。

Ts’o仍然不放弃,他认为kselftest的文档从来没有提起这种测试方式。而且在init进程启动之前,有其他测试可以跑,不过并不是kselftest framework的一部分:

init执行之前kernel是有test modules可以运行——不过严格来说这并不是kselftests的一部分,也没有任何架构性的支持。而kselftests_harness头文件里面明确写了你的test case应该运行在userspace。

Overlaps

KUnit和kselftest的功能也可能有一些重复。Knut Omang是Kernel Test Framework项目的一员,认为讨论中大家把两种不通的测试混在一起讨论了。一种是独立测试某个特定子系统的,这个子系统的开发者需要能快速并且重复运行这种测试;另一种是需要测试多个子系统的互相交互,通常应用于regression test suite里,或者continuous-integration的场景,当然开发者也会进行这种测试。ext4专门的unit test应该算是第一类,而xfstests就算是第二种类型。

Omang认为两类测试应该还是能够合并进同一个测试工具的,使用通用的configration文件,测试报告格式,等等。这就是KTF打算做的事情。不过Ts’o很怀疑可以用一个测试框架来一路走下去。目前已经有多种测试框架存在了,包括xfstests, blktests, kselftest等等。Omang还觉得UML在这种场景下把水搅得更混了:

使用UML的主要问题是你还是逃不掉启动复杂的kernel运行时环境的,而你真正需要的测试其实只是在user space上下文编译几个kernel源代码文件,然后用Valgrind等user space工具来检查这段代码。这里主要挑战是怎样在这种环境里编译好那几个源代码文件,因为通常它们编译时都会依赖一堆内核宏定义。这就是为什么你们退而求其次来找到UML。

不过Ts’o看法不同:

在user land编译几个kernel源文件并不难,只要写一堆stub函数即可。对文件系统来说,我需要虚拟出block device layer,还有VFS层的大部分函数,scheduler和内核锁等相关函数,等等。实际上,UML就像是这堆stub函数。所以Frank说的KUnit没有提供任何支持,这一点我不同意。KUnit和ML配合着用,让我们测试内部接口的时候简单的多了,特别是相比于把这些内核源代码编译成userspace test程序来说,简单的多得多。

Gunthorpe也觉得有一些功能重复,他区分测试类型的思路跟Omang很类似,他认为没有太多用户会使用kselftest_harness.h这里的接口,因此是应该考虑把两者重复的部分统一起来:

虽然有人不赞成,不过KUnit确实跟kselftest有很大功能重复。无论是在轻量级UML环境里跑短小的test case,还是在重量级的VM环境里跑一些偏上层的测试,最好都能用相同的框架来写in-kernel tests。对部分人来说,能在重量级的VM环境里跟其他上层测试同时运行所有UML测试,可能也会觉得很有用处。

看一下现有的selftest代码,可以看到一些Kunit正在添加的test。kselftest_harness.h内部的EXPECT_*和ASSERT_* 这些宏定义就跟KUNIT_EXPECT_*和KUNIT_ASSERT_*定义非常类似。

Ts’o不反对把两个框架统一起来,不过他认为kselftest_harness.h需要重构一下,in-kernel test才能够开始用它。Gunthorpe后来回复的时候似乎改变了一些想法,他觉得统一两种场景的花费太大可能不值得了:

用kunit做in-kernel test,用kselftest_harness做userspace test似乎是一个比较合理的分界线。要把kernel和userspace统一起来感觉比较难,可能并不值得。除非有人愿意做出很漂亮的工作来实现出来。

最后,Rowand想要看到一个KUnit为什么有必要存在的证明,以及它跟kselftest有什么不同。Higgins想要一些具体的建议,关于KUnit缺少什么部分。Rowand回复指出patch里要写清楚正当理由:

讨论下来有一点应该很明确了,部分开发者并不理解kselftest包含in-kernel test,以为它只有userspace tests。因此,KUnit其实是相同功能的第二种实现方式。(可能会有争论kselftest和KUnit提供了那些in-kernel test功能,以及有多少是重复的。所以这里我说的相同功能可能并不是最终结论)因此需要把这个关键信息记录下来在patch内解释清楚。

不过Gunthorpe仍然不同意:“在我看来,Brendan已经提供了足够多的信息来讲明Kunit的必要性”。关于kselftest是否提供了in-kernel的framework似乎变成了双方争论的难点。Ghunthorpe相信in-kernel kselftest代码应该被改成使用KUnit,他非常期待看到这样的改动。

讨论进入尾声,Higgins在5月13日贴出了v3版本的patch set,几天后又更新到了v4版本。他解决了v2里人们提及的一些代码问题,也增加了文档介绍了如何在UML之外的体系架构上运行测试。这次没有太多反对意见,很可能KUnit能够在5.3版本里合入。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

极度欢迎将文章分享到朋友圈 

长按下面二维码关注:Linux News搬运工,希望每周的深度文章以及开源社区的各种新近言论,能够让大家满意~

阅读原文...


Avatar

一文览尽 FacebookICML 2019 成果集锦

上一篇

任正非自画像:华为的成功,与我不自私有一点关系

下一篇

您也可能喜欢

评论已经被关闭。

插入图片
LWN:Linux kernel要有几种test framework?

长按储存图像,分享给朋友