Table of Contents
Introduction
Linux exposes a rich set of system APIs that let you talk directly to the kernel and core system services. These APIs sit below libraries like the C standard library, higher level languages, and command line tools. Understanding them is essential if you want to write serious Linux tools in C, or if you want to understand what higher level languages and utilities are really doing under the hood.
This chapter focuses on what is specific to Linux system APIs. It assumes you already know basic C programming, process concepts, and general Linux usage. The goal is not to catalog every call, but to show how Linux APIs are organized, where they live, how to discover them, and what makes Linux specific compared to generic POSIX.
User space, kernel, and system calls
From a tool writer’s perspective, Linux is divided into user space and kernel space. Your programs run in user space. The kernel controls hardware, memory, processes, and security. Linux system APIs are the controlled gates between these two worlds.
At the lowest level, the kernel exposes system calls. These are entry points where execution jumps from user space into the kernel. In C you normally do not invoke system calls with machine instructions; you call functions from libc that wrap them, such as open, read, write, fork, and execve. On Linux, most of these are thin wrappers around a single syscall instruction, but you usually do not see that.
A good mental model is:
$$\text{Your tool} \rightarrow \text{libc wrapper} \rightarrow \text{Linux system call} \rightarrow \text{kernel}$$
Many Linux APIs follow this pattern. Some features are pure user space libraries, but the core of process control, files, networking, IPC, and memory management involves system calls.
Linux system calls form a stable contract between user space and the kernel. Avoid calling raw system calls directly unless you have a specific reason. Prefer the documented C library interfaces, which handle details like portability, calling conventions, and subtle behavior.
Where Linux APIs are documented
When you build tools that use Linux APIs, your main references are:
Manual pages in section 2 and 3. Section 2 documents system calls, such as man 2 open. Section 3 documents library functions, such as man 3 printf. Many Linux specific calls or extensions have their own pages like epoll, signalfd, inotify, and fanotify.
The man 7 pages. Section 7 contains overview and concept pages, including man 7 signal, man 7 ip, man 7 capabilities, and man 7 socket. Linux specific APIs often have overview documents here.
Kernel and glibc headers in /usr/include and /usr/include/linux. Portable APIs are generally declared in standard headers like <unistd.h>, <fcntl.h>, <sys/types.h>. Linux specific calls or flags often come from headers like <sys/epoll.h>, <sys/inotify.h>, <sys/signalfd.h>, and from kernel headers under <linux/...>.
The Linux man-pages project and kernel documentation. On a development system, these are available via man. Online, you can consult the Linux man pages project site or the kernel’s online documentation tree.
When you see a man page that says “Linux specific”, you are looking at an API that will not exist on generic POSIX or non Linux systems. Tools tightly bound to those calls will be Linux only.
Headers, feature test macros, and Linux extensions
Linux exposes both POSIX compliant APIs and Linux specific extensions. When writing tools, you may choose to stick to portable APIs or embrace Linux only features.
Some Linux extensions are only visible if you define feature test macros before including any headers. For example, to use certain GNU and POSIX extensions you might define: