Comment by t-3
1 month ago
It is somewhat documented. man 2 syscalls tells me they are defined in /usr/include/asm/unistd.h. That file include /usr/include/asm/unistd_{32,64}.h, which contain the definitions on my amd64 linux box. On my aarch64 they're in /usr/include/asm-generic/unistd.h, but the syscalls manfile doesn't mention the changed path.
Those are glibc headers not Linux kernel headers.
The glibc headers do not necessarily match your current Linux kernel.
You should use the glibc headers when you use the glibc generic syscall wrappers, but otherwise you must not consider them as an authoritative source for syscalls, because they frequently do not contain all the syscalls provided by your current kernel.
> Those are glibc headers not Linux kernel headers.
You're right in principle: but more precisely, they are the kernel headers for the kernel version which the system glibc was built against. But they are actually from the kernel source, not the glibc source.
The manpage defines the interface in terms of sys/syscall.h where it leads to the right place on every platform I've ever worked on, and which is where I would first look, but yeah, maybe not all sections are clear.
That's the syscall(9) manpage, not the syscalls(2) manpage. syscall(9) is present on BSD as well, and on my OpenBSD box points me to sys/syscall.h which has the syscalls. On linux sys/syscall.h is empty and includes asm/unistd.h.
The manpage syscall(2) exists on both Linux and FreeBSD, while syscall(9) does not exist on either of them.
On Linux there is also a syscalls(2) manpage, while no syscalls page exists on FreeBSD.
These man pages belong to libc (e.g. glibc on Linux), not to the kernel. This distinction does not matter on FreeBSD and other *BSD, where the kernel and the standard C library are always synchronized, but it matters on Linux, where glibc and the kernel are developed independently, so their lists of syscalls are not the same. Typically glibc is synchronized with an older Linux kernel, not with your current kernel.
1 reply →
That syscall man page is from glibc and provides information about how you can invoke syscalls through glibc.
It does not have any direct connection with the Linux kernel. Because the Linux kernel promises that the syscall interface is stable, in the normal situation when the kernel is newer or at least of the same age with glibc, all the syscalls that can be invoked through glibc should be supported by the kernel, but the kernel may support extra syscalls.
If you install a kernel that is older than glibc, which may happen in some embedded systems that are compatible only with some old kernels, then it may be that the kernel does not support all the syscalls from the glibc headers.