glibc 维护者在 LPC 2025 上讨论缺失的系统调用封装

在2025年Linux Plumbers Conference（LPC）会议演讲的后续讨论中，Carlos O'Donell在今年的大会上再次回到了GNU C库（glibc）的系统调用包装器这一话题。这一次，另一位glibc维护者Florian Weimer也加入了他的讨论。他们的目的是介绍过去一年中，对于那些缺少glibc包装器、只能通过syscall()访问的Linux系统调用，有哪些进展。此外，他们也希望听取与会者在这一领域的需求。

O'Donell首先描述了“我们试图解决的问题”，即让内核通过系统调用暴露的功能能够方便地从C库中使用。如果某个系统调用已经可用，说明该功能已经添加到内核中，并且头文件中有相应的入口来访问它。他表示，开发者希望访问新系统调用的原因有很多，比如测试、示例、梳理ABI问题等等。

O'Donell想要讨论的是所有其他缺少任何glibc接口（除了syscall()之外）的系统调用。创建系统调用包装器涉及大量复杂性，“因为ABI问题、过程调用标准、参数传递给内核的方式、你所拥有的特殊内核参数调用接口”等等。因此，编写可移植的系统调用包装器版本很困难，这意味着它们最终变成了“奇怪的、针对特定架构的东西”。他说，创建这些包装器不应该需要理解所有这些内容。

因此，在去年的大会上，他提出愿意“审查、指导、辅导系统调用包装器走完整个流程”。当内核开发者添加一个系统调用时，他们需要与多个社区合作才能真正将功能提供给用户，比如musl libc、LLVM-libc等。他的提议是尝试让系统调用包装器进入glibc的过程更加容易。

“嗒哒”，他说道，同时展示了一张幻灯片，上面是André Almeida提交的为futex_waitv()添加包装器的RFC补丁集。O'Donell感谢了在场的Almeida接受了他的提议，并指出他们两人一直在与Adhemerval Zanella一起完善这个补丁集。O'Donell说，futex接口很复杂；它是一个“多路复用接口，包含非常棘手、繁琐的部分”，但包装器的工作正在进行中。“我认为这是一系列美好补丁的开端，是与我们合作确保包装器到位的第一步。”

接下来，他转向了那些没有包装器的具体系统调用。他查看了x86-64架构，Linux内核树中有386个系统调用。其中，glibc导出了292个“同名全局符号”，这意味着glibc中有一个与系统调用同名的C函数。该调用“基本上实现了那个功能；我并不是说它完全精确或完全相同”。例如，有些包装器需要将内核类型映射为等效的用户空间ABI类型。

他说，目前是机械生成的汇编语言包装器和手动编写的C包装器的混合，这也许不太理想，但这就是现状。自2014年以来，glibc开发者一直在研究机械生成包装器的方法，“但机械转换过程太过繁琐”，因为需要考虑太多不同的细节。所以这个项目从未完成。

除了这292个之外，还有16个glibc调用的名称与系统调用不同，因为行为不同。这样还剩77个没有包装器的系统调用。Toolchains track的组织者Nick Desaulniers询问这77个中是否有“已经废弃、应该被列入移除计划”的。O'Donell热情地表示确实有：“绝对有”；他指出Desaulniers已经预判了他的下一张幻灯片（见下文），其中包含了答案。这张幻灯片上有一份由O'Donell、Weimer和Zanella编写的关于添加包装器优先级的意见列表。O'Donell说，他并不期望与会者真正去读这张幻灯片，只是希望大家对不同分类桶有一个大致了解。第一个桶是“核心内核功能”，Weimer和O'Donell来回讨论，把一些调用从这个桶移到“领域特定功能”桶，又移回来。“对于‘领域特定功能’，我认为我们不需要为它们提供包装器”，O'Donell说。该列表最上面是io_uring的调用，它们不是包装器的优先目标，因为开发者会直接使用liburing。如果事实证明并非如此，即内核和用户空间开发者都在要求包装器，glibc开发者可能会在某个时候添加它们，但目前有更高优先级的目标。

另一个较低优先级的领域是实现C库实现所需接口的系统调用。他说，这些可以直接从C库代码中调用，并不是许多应用开发者需要的功能。然后是幻灯片底部列出的“已经废弃的东西”，“我们永远不会实现”。

回到高优先级的系统调用，他指出内核暴露了许多需要包装器的并发原语，比如futex_waitv()。这正是Almeida工作背后的原因，而这些包装器在其他地方也需要，比如在libstdc++中，O'Donell说。由于它们不可用，“我们只好凑合，libstdc++直接调用futex()”，这本来不应该发生。

除了并发原语之外，还有各种用于调度、隔离、内存管理、文件系统等的调用。O'Donell说，在核心内核功能部分的底部是map_shadow_stack()，它的优先级可能没那么高。但一旦futex_waitv()进入，作为核心内核功能类别的一部分，开始处理更多并发调用就是合理的。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）