[dundarious]

There's nothing strange in this domain about relying on people to read the C header. On a running system `man syscall` points you to sys/syscall.h. Read /usr/include/sys/syscall.h which says it gets the actual numbers from kernel header asm/unistd.h. Read that and it redirects in simple if-else fashion to the specific header, e.g., asm/unistd_64.h. That file is clear as day:

    #ifndef _ASM_UNISTD_64_H
    #define _ASM_UNISTD_64_H

    #define __NR_read 0
    #define __NR_write 1
    #define __NR_open 2
    ...
    #endif /* _ASM_UNISTD_64_H */

That was all on my x86-64 machine. Same again on an aarch64:

    #define __NR_io_setup 0                                                                                                               
    #define __NR_io_destroy 1                                                                                                             
    #define __NR_io_submit 2 
    ...

I'm not saying that wanting a table on the web or a spreadsheet or whatever is bad or wrong, but it is not a difficult or obtuse task. I think people who write code that does such things are generally familiar with just reading some C headers, or if they're already using C they just `#include <sys/syscall.h>` and call it a day.

Then on the calling convention, etc., the nolibc project (in the kernel tree) is great for learning or smaller projects (but of course Agner Fog's docs are the "canon" there).

[adrian_b]

The header mentioned by you does not belong to Linux.

It is a glibc header. It is the right header to use when you invoke syscalls using the generic syscall wrappers provided by glibc.

However, glibc frequently is not synchronized with your current Linux kernel, but with some older version, so this header typically does not contain the most recently added syscalls. Even for the older syscalls, I am not certain that glibc provides all of them.

The authoritative list of syscalls must be gathered from the Linux kernel headers, not from glibc. What must be done for this is not as simple as you would expect, hence the several places mentioned by various posters where this tedious work has been done.

[dundarious]

True, I've had to deal with that for newer syscalls and the few that glibc neglects to cover. I didn't mention it, and I suppose the original post was about lack of kernel documentation, so mentioning a glibc source (or musl or whatever) is misleading in a way I didn't originally consider.