Linux kernel interfaces

The Linux API is composed out of the System Call Interface of the Linux kernel, the GNU C Library (by GNU), libcgroup,[1] libdrm, libalsa and libevdev[2] (by freedesktop.org).

Linux API vs. POSIX API

The Linux API is the kernel–user space API, which allows programs in user space to access system resources and services of the Linux kernel.[3] It is composed out of the System Call Interface of the Linux kernel and the subroutines in the GNU C Library (glibc). The focus of the development of the Linux API has been to provide the usable features of the specifications defined in POSIX in a way which is reasonably compatible, robust and performant, and to provide additional useful features not defined in POSIX, just as the kernel–user space APIs of other systems implementing the POSIX API also provide additional features not defined in POSIX.

The Linux API, by choice, has been kept stable over the decades through a policy of not introducing breaking changes; this stability guarantees the portability of source code.[4] At the same time, Linux kernel developers have historically been conservative and meticulous about introducing new system calls.

Much available free and open-source software is written for the POSIX API. Since so much more development flows into the Linux kernel as compared to the other POSIX-compliant combinations of kernel and C standard library, the Linux kernel and its API have been augmented with additional features. As far as these additional features provide a technical advantage, programming for the Linux API is preferred over the POSIX-API. Well-known current examples are udev, systemd and Weston.[5] People such as Lennart Poettering openly advocate to prefer the Linux API over the POSIX API, where this offers advantages.[6]

At FOSDEM 2016, Michael Kerrisk explained some of the perceived issues with the Linux kernel's user-space API, describing that it contains multiple design errors by being non-extensible, unmaintainable, overly complex, of limited purpose, in violation of standards, and inconsistent. Most of those mistakes cannot be fixed because doing so would break the ABI that the kernel presents to the user space.[7]

The C standard library

The GNU C Library is a wrapper around the Linux kernel System Call Interface.

A C standard library is a wrapper around the system calls of the Linux kernel; the combination of the Linux kernel System Call Interface and a C standard library is what builds the Linux API. Some popular implementations of the C standard library are

• glibc
• uClibc
• klibc
• Newlib
• musl
• dietlibc
• libbionic and libhybris

The Linux API and the Linux ABI

The term Linux ABI refers to a kernel–user space ABI. The application binary interface refers to the compiled binaries, in machine code. Any such ABI is therefore bound to the instruction set. Defining a useful ABI and keeping it stable is less the responsibility of the Linux kernel developers or of the developers of the GNU C Library, and more the task for Linux distributions and independent software vendors (ISVs) who wish to sell and provide support for their proprietary software as binaries only for such a single Linux ABI, as opposed to supporting multiple Linux ABIs.

An ABI has to be defined for every instruction set, such as x86, x86-64, MIPS, ARMv7-A (32-Bit), ARMv8-A (64-Bit), etc. with the endianness, if both are supported.

It should be able to compile the software with different compilers against the definitions specified in the ABI and achieve full binary compatibility. Compilers that are free and open-source software are e.g. GNU Compiler Collection, LLVM/Clang.

There are a lot of kernel-internal APIs for all the subsystems to interface with one another. These are being kept fairly stable, but there is no guarantee for stability. In case new research or insights make a change seem favorable, an API is changed, all necessary rewrite and testing have to be done by the author.

The Linux kernel is a monolithic kernel, hence device drivers are kernel components. To ease the burden of companies maintaining their (proprietary) device drivers out-of-tree, stable APIs for the device drivers have been repeatedly requested. The Linux kernel developers have repeatedly denied guaranteeing stable in-kernel APIs for device drivers. Guaranteeing such would have faltered the development of the Linux kernel in the past and would still in the future and, due to the nature of free and open-source software, are not necessary. Ergo, by choice, the Linux kernel has no stable in-kernel API.[15]

Since there are no stable in-kernel APIs, there cannot be stable in-kernel ABIs.[16]

OpenGL is indeed an abstraction API to make use of diverse GPUs of multiple vendors without the need to program for each one specifically.

But the implementation of the OpenGL-specification is executed on the CPU in the context of the running operating system. One design goal of Vulkan was to make the "graphics driver", i.e. the implementation of the graphics API, do less.

For several use cases, the Linux API is considered too low-level and higher abstraction APIs are used. Such of course still need to work on top of the low-level Linux APIs. Examples:

• Implementation of the OpenGL and Vulkan specifications in proprietary Linux graphics drivers and the free and open-source implementation in Mesa.
• Implementation of the OpenAL specification.
• Simple DirectMedia Layer: abstraction API for input/sound/etc. available for many operating systems.
• Simple and Fast Multimedia Library: like above.

• The Linux Programming Interface by Michael Kerrisk
• Semaphore (programming)
• system call – is a function to facilitate programs to request services from the kernel
  • eventfd()
  • netlink – socket family used for IPC between kernel and user space processes, designed as the successor of ioctl; Netlink was added by Alan Cox during Linux kernel 1.3 development as a character driver interface to provide multiple kernel and user-space bidirectional communications links. Then, Alexey Kuznetsov extended it during Linux kernel 2.1 development to provide a flexible and extensible messaging interface to the new advanced routing infrastructure. Since then, Netlink sockets have become one of the main interfaces that kernel subsystems provide to user-space applications in Linux. Modern WNIC drivers use it to communicate with user-space.
• Windows API – article on various API available on Microsoft Windows operating systems
  • windows.h – header file for the C programming language which contains declarations for all of the functions in the Windows API
• Wine – a compatibility layer between Linux and programs written for Microsoft Windows
• libhybris – compatibility layer between Linux and programs written for Android

• The Linux Kernel API 5.0, Memory Management APIs 5.0 (new sphinx format)
• The API of Linux kernel 2.6.20 and 4.12 (in deprecated htmldocs format)
• API/ABI changes review for Linux
• The Linux Programming Interface book, Linux and glibc API changes since The Linux Programming Interface was released in 2010
• Interactive Linux kernel map with main API functions and structures, PDF version
• Linux Device Drivers by Jonathan Corbet, Greg Kroah-Hartman and Alessandro Rubini, 3rd edition
• Linux Kernel Linked List Explained Archived 2009-09-25 at the Wayback Machine