Kernel Developers Debate Having An Official Linux System Wrapper Library

As new system calls get added to the Linux kernel, these syscalls generally get added to Glibc (and other libc libraries) for developers to make easy use of them from their applications. But as Glibc doesn't provide 1:1 coverage of system calls, sometimes is delayed in their support for new calls, and other factors, there is a discussion about providing an official Linux system wrapper library that could potentially live as part of the kernel source tree.

This weekend was the initial proposal for having an official Linux system wrapper library. Though that initial proposal is a bit flawed in saying that "glibc is basically not adding new system call wrappers", as they are, just sometimes it takes a while among other factors. But it is accurate in reflecting a problem with the status quo.

Glibc does continue adding wrappers for new Linux kernel system calls, but there are some issues. Florian Weimer did a nice job clarifying that in some cases there are issues in not having enough documentation from kernel developers on the new calls / lack of clear specifications, some syscalls being misdesigned, problems with some system calls like introducing boot delays, collisions over function names, and similar complexities.

There is also the fact that Linux supports multiple C libraries and at the same time Glibc supports more operating systems than just Linux. One possible solution to that would be if there was a libc interface as part of the operating system itself.

The very vibrant discussion over the past two days in the kernel thread does make it clear that there is room for improvement over exposing new system calls to userspace. But as far as the optimal path forward, there doesn't appear to be any clear consensus at this stage.