://lwn.net/Articles/726021/

内核ABI规范化

在Open Source Summit Japan上,Sasha Levin谈了谈内核ABI的规范化,并介绍到目前为止取得的一些进展,当然还有大量工作尚未完成。主流观点认为,内核新增patch不应该破坏内核ABI兼容性,比如,一个运行在4.0内核上的应用程序,也需要能在更新的5.0内核上运行。但遗憾的是,当前还没有工具检测ABI的兼容性是否被破坏。于是乎,只能依靠用户去发现这种行为,然后报告到社区,由内核开发者修复。

由于没有ABI规范,一些基础软件,如glibc, qemu, strace, 为了保证可靠性,在系统调用前,往往进行重复的参数检查;这在性能方面带来一定损耗。同时,内核在系统调用路径上操作参数时,也容易破坏ABI的兼容性。更棘手的是,新发布了一个内核版本,一段时间后,用户发现一些老程序不能在新内核上运行(ABI不兼容);于此同时,另外一些用户基于新的ABI接口开发了新的应用。这时,内核开发者将面临一个两难的决策,不管如何,总会让一些用户不开心。

倘若ABI不能向后兼容,还会带来许多其它噩梦,不一一详述。因此,内核开发者需要一种内嵌在内核代码中的“规范”,用于描述哪些修改内核的行为是被禁止的。该规范一石二鸟,即强制要求内核和用户程序行为规范化,又解决了向后兼容问题。然而,该“规范”到底长什么样子呢?是人类可读的文档,还是机器可读的代码?从内核角度来看,需要能根据该规范生成代码,用于系统调用参数和返回值检查(这是ABI兼容性的一部分)。从用户态来看,它需要使应用程序和库访问内核ABI更容易,更有保障。

目前,最难的是如何确定规范的格式。open() 和 close() 系统调用很容易描述,但是许多其它系统调用更复杂,且相互耦合。因此,spec文档需要更详细的è®°录各个系统调用的行为,要比现有的man帮助文档内容更丰富,更偏向于实现原理。其次,这些spec文档需要经过严格的测试,以保证它没有破坏现有用户态程序的行为。

最后,Levin说自己正与syzkaller的开发者合作,参与一些前期工作, 希望对ABI规范化有所帮助。