Kernel Development – APIs Without System Calls

System calls per se are a concept. They represent actions that processes can ask the kernel to perform.

Those system calls are implemented in the kernel of the UNIX-like system. This implementation (written in C, and in asm for small parts) actually performs the action in the system.

Then, processes use an interface to ask the system for the execution of the system calls. This interface is specified by POSIX. This is a set of functions of the C standard library. They are actually wrappers, they may perform some checks and then call a system-specific function in the kernel that tell it to do the actions required by the system call. And the trick is that those functions which are the interface are named the same as the system calls themselves and are often referred directly as "the system calls".

You could call the function in the kernel that perform the system call directly through the system-specific mechanism. The problem is that it makes your code absolutely not portable.

So, a system call is:

• a concept, a sequence of action performed by the kernel to offer a service to a user process
• the function of the C standard library you should use in your code to get this service from the kernel.

For most of the system calls with man pages in section 2, the man pages actually describe the C library wrappers. The exceptions are usually mentioned explicitly, like gettid that @Sergei Kurenkov refer's to in their answer:

NOTES Glibc does not provide a wrapper for this system call; call it using syscall(2).

Similarly with pivot_root (which isn't that useful for general applications), tgkill (which performs the low-level function of pthread_kill). Then there's readdir, where the actual system call is somewhat different from the library function:

DESCRIPTION This is not the function you are interested in. Look at readdir(3) for the POSIX conforming C library interface. This page documents the bare kernel system call interface, which is superseded by getdents(2).

Note that there has to be some sort of wrapper. Function calls are made using the C calling conventions, which is different from the calling convention of the kernel interface. Usual function calls are made with the call assembly instruction (or similar), kernel calls with syscall or int 0x80 (and that's not counting stuff like gettimeofday or getpid in the vdso). The compiler doesn't (need to) know which function calls map to an an actual kernel call.

Even with the "usual" system calls, the C library wrapper acts slightly differently from the bare system call: The system calls return the error codes as varying negative values (if you look at the Linux kernel code, you'll see a lot of returns like return -EPERM;). The C library wrapper turns all such return values to -1, and moves the actual error code to errno.