On Mon, 12 Nov 2018, Florian Weimer wrote: > For that use case, a machine-readable system call ABI specification is > the only reasonable approach: Some people want inline system calls, I also think it's much more likely to be of use to glibc than any syscall library provided by the kernel. I don't think a syscall library provided by the kernel is likely to be of use for implementing glibc functions, but some kind of textual ABI specification might at least be of use for checking that syscall macro calls / syscalls.list entries are consistent with what the kernel thinks its ABI is. (Hopefully there would be automated tests on the kernel side as well of some kind of consistency between the ABI specification and the kernel.) strace is indeed a more obvious potential consumer of such a description of syscall ABIs. I'd think a syscall library would more likely be something a few applications would use if they want to access a syscall that for whatever reason glibc doesn't have a wrapper for yet - not something useful for glibc itself to call or link against. > and for application programmer's sanity, make sure that the kernel adds > generic system calls in a single version, across all architectures. That would be strongly desirable for glibc as well - a way of ensuring that the kernel rapidly fails CI tests and does not get released if new syscalls are only present on some architectures (including e.g. being missing from some compat syscall tables, or defined in asm/unistd.h but not in the actual syscall table, or vice versa - or some way of making sure such inconsistencies cannot occur by eliminating duplicate copies of the syscall list information in the sources). When we have compatibility code in glibc for the absence of some syscall, we can only eliminate that code when the oldest kernel version supported by glibc is new enough to have the syscall on whichever glibc architecture was slowest to introduce the syscall in the kernel - and that can often be years after the first architectures gained support for that syscall in the kernel. -- Joseph S. Myers joseph@xxxxxxxxxxxxxxxx