Linux kernel interfaces

Linux kernel APIs and ABIs

This article is written like a personal reflection, personal essay, or argumentative essay that states a Wikipedia editor's personal feelings or presents an original argument about a topic. Please help improve it by rewriting it in an encyclopedic style. (July 2014) (Learn how and when to remove this message)

|

Linux API, Linux ABI, and in-kernel APIs and ABIs

The Linux kernel provides multiple interfaces to user-space and kernel-mode code. The interfaces can be classified as either application programming interface (API) or application binary interface (ABI), and they can be classified as either kernel-user space or kernel-internal.

## Linux API

[edit]

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 includes the kernel-user space API, which allows code in user space to access system resources and services of the Linux kernel.[3] It is composed of the system call interface of the Linux kernel and the subroutines in the C standard library. 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.[citation needed]

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,[citation needed] the Linux kernel and its API have been augmented with additional features. Programming for the full Linux API, rather than just the POSIX API, may provide advantages in cases where those additional features are useful. 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]

###  System call interface of the Linux kernel

[edit]

The system call interface of a kernel is the set of all implemented and available system calls in a kernel. In the Linux kernel, various subsystems, such as the Direct Rendering Manager (DRM), define their own system calls, all of which are part of the system call interface.

Various issues with the organization of the Linux kernel system calls are being publicly discussed. Issues have been pointed out by Andy Lutomirski, Michael Kerrisk and others.[8][9][10][11]

### The C standard library

[edit]

The GNU C Library is a wrapper around the Linux kernel system call interface.

A C standard library for Linux includes wrappers 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

Although the landscape is shifting, amongst these options, glibc remains the most popular implementation, to the point of many treating it as the default and the term equivalent to libc.

#### Additions to POSIX

[edit]

As in other Unix-like systems, additional capabilities of the Linux kernel exist that are not part of POSIX:

* cgroups subsystem, the system calls it introduces and libcgroup[1]
* The system calls of the Direct Rendering Manager, especially the driver-private ioctls for the command submission, are not part of the POSIX specifications.
* Advanced Linux Sound Architecture could set system calls, which are not part of the POSIX specifications
* The system calls `futex` (fast userspace mutex), `epoll`, `splice`, `dnotify`, `fanotify`, and `inotify` have been exclusive to the Linux kernel so far.
* The system call `getrandom` was introduced in version 3.17 of the Linux kernel mainline[12]
* `memfd` was proposed by the kdbus developers[13]
* `memfd_create` was merged into the Linux kernel mainline in kernel version 3.17
* `readahead` initiates a file "read-ahead" into page cache

DRM has been paramount for the development and implementations of well-defined and performant free and open-source graphics device drivers without which no rendering acceleration would be available at all, only the 2D drivers would be available in the X.Org Server. DRM was developed for Linux, and since has been ported to other operating systems as well.[14]

### Further libraries

[edit]

* libdrm (for Direct Rendering Manager)
* libnl (The libnl suite is a collection of libraries providing APIs to netlink protocol based Linux kernel interfaces.)
* libevdev (for evdev)
* libasound (Advanced Linux Sound Architecture)

## Linux ABI

[edit]

This article needs attention from an expert in free and open-source software, software or computing. The specific problem is: This section mostly ignores the kernel-userspace ABI (that is very real and important thing) and jumps into userspace-to-userspace APIs. WikiProject Free and open-source software, WikiProject Software or WikiProject Computing may be able to help recruit an expert. (February 2018)

|

The Linux API and ABI

Main articles: x32 ABI and Linux Standard Base

The Linux ABI is a kernel–user space ABI. As ABI is a machine code interface, the Linux ABI is 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.

## In-kernel APIs

[edit]

Many kernel-internal APIs exist, allowing kernel subsystems to interface with one another. These are being kept fairly stable, but there is no guarantee for stability. A kernel-internal API can be changed when such a need is indicated by new research or insights; all necessary modifications 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 outside of the main kernel 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]

## In-kernel ABIs

[edit]

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

## Abstraction APIs

[edit]

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 many use cases, the Linux API is considered too low-level, so APIs of higher abstraction must be used. Higher-level APIs must be implemeted on top of lower-level 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.

## See also

[edit]

* Linux portal

* File descriptor – System resource identifier in operating systems
* Hybris (software) – Compatibility layer to run Android drivers on glibc or musl-based Linux systemsPages displaying short descriptions of redirect targets
* The Linux Programming Interface – Book by Michael Kerrisk
* netlink – Linux kernel interface for inter-process communication between processes
* Semaphore (programming) – Variable used in a concurrent system
* system call – Way for programs to access kernel services
* Windows API – Microsoft's core set of application programming interfaces on Windows
* windows.h – Defines access to the Windows API in C language syntax
* Wine (software) – Windows compatibility software

## References

[edit]

1. ^ a b "ControlGroupInterface". freedesktop.org.
2. ^ "libevdev". freedesktop.org.
3. ^ Alessandro Rubini (2006-11-02). "Kernel System Calls". linux.it. Retrieved 2014-11-11.
4. ^ Linus Torvalds (2012-12-23). "Re: [Regression w/ patch] Media commit causes user space to misbahave (was: Re: Linux 3.8-rc1)". Linux kernel mailing list. Retrieved 2014-08-26. "If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs."
5. ^ "Choosing between portability and innovation". LWN.net. 2011-03-02.
6. ^ "Interview: Lennart Poettering - Lennart Poettering will give a talk about "Systemd: beyond init" at FOSDEM 2011". fosdem.org. 2011. Retrieved 2014-06-16. "In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!"
7. ^ Michael Kerrisk (2016-01-31). "How to design a Linux kernel API". Retrieved 2016-02-04.
8. ^ "System Call Organization".
9. ^ "Making a universal list of syscalls?". LKML. 2014-02-27.
10. ^ "Flags as a system call API design pattern". LWN.net. 2014-02-12.
11. ^ "On vsyscalls and the vDSO". LWN.net. 2011-06-08.
12. ^ "[PATCH, RFC] random: introduce getrandom(2) system call". LKML. 2014-07-17.
13. ^ "memfd.c". GitHub. Archived from the original on 2014-04-22.
14. ^ "NetBSD 7.0 Will Finally Have DRM/KMS Drivers". Phoronix. 2014-03-19.
15. ^ "The Linux Kernel Driver Interface".
16. ^ "Analysis of ABI changes in the Linux kernel". Andrey Ponomarenko's ABI laboratory. 2016-03-15.

## External links

[edit]

* 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[usurped] with main API functions and structures, PDF[usurped] version
* Linux Device Drivers[usurped] by Jonathan Corbet, Greg Kroah-Hartman and Alessandro Rubini, 3rd edition
* Linux Kernel Linked List Explained Archived 2009-09-25 at the Wayback Machine

* v
* t
* e

Linux kernel

Organization|

| Kernel|

* Linux Foundation
* Linux Mark Institute
* Linus's law
* Tanenbaum–Torvalds debate
* Tux
* SCO disputes
* Linaro
* GNU GPL v2
* menuconfig
* Supported computer architectures
* Version history
* Criticism

|

Support|

* Developers
* The Linux Programming Interface
* kernel.org
* LKML
* Linux conferences
* Users
* Linux User Group (LUG)

People|

* Werner Almesberger
* H. Peter Anvin
* Jens Axboe
* Moshe Bar
* Suparna Bhattacharya
* Andries Brouwer
* Rémy Card
* Alan Cox
* Matthew Garrett
* Avi Kivity
* Con Kolivas
* Greg Kroah-Hartman
* Benson Leung
* Robert Love
* David S. Miller
* Ingo Molnár
* Andrew Morton
* Hans Reiser
* Rusty Russell
* Shuah Khan
* Linus Torvalds
* Theodore Ts'o
* Stephen Tweedie
* Harald Welte
* Chris Wright

Technical|

| Debugging|

* CRIU
* ftrace
* kdump
* Linux kernel oops
* SystemTap
* BPF

|

Startup|

* vmlinux
* System.map
* dracut
* initrd
* initramfs

ABIs|

* Linux Standard Base
* x32 ABI

APIs|

| Kernel|

| System Call
Interface|

* POSIX
* ioctl
* select
* open
* read
* close
* sync
* …
* Linux-only
* futex
* epoll
* splice
* dnotify
* inotify
* readahead
* …

|

In-kernel|

* ALSA
* Crypto API
* io uring
* DRM
* kernfs
* Memory barrier
* New API
* RCU
* Video4Linux
* IIO

Userspace|

| Daemons,
File systems|

* bpffs
* configfs
* devfs
* devpts
* debugfs
* FUSE
* hugetlbfs
* pipefs
* procfs
* securityfs
* sockfs
* sysfs
* tmpfs
* systemd
* udev
* Kmscon
* binfmt_misc

|

Wrapper
libraries|

* C standard library
* glibc
* uClibc
* Bionic
* libhybris
* dietlibc
* EGLIBC
* klibc
* musl
* Newlib
* libcgroup
* libdrm
* libalsa
* libevdev
* libusb
* liburing

Components|

* Kernel modules
* BlueZ
* cgroups
* Console
* bcache
* Device mapper
* dm-cache
* dm-crypt
* DRM
* EDAC
* evdev
* Kernel same-page merging (KSM)
* LIO
* Framebuffer
* LVM
* KMS driver
* Netfilter
* Netlink
* nftables
* Network scheduler
* perf
* SLUB
* zram
* zswap

* Process and I/O schedulers:
* Brain Fuck Scheduler
* Completely Fair Scheduler (CFS)
* Earliest eligible virtual deadline first (EEVDF)
* Noop scheduler
* O(n) scheduler
* O(1) scheduler
* SCHED_DEADLINE
* SCHED_FIFO
* SCHED_RR

* Security Modules: AppArmor
* Exec Shield
* seccomp
* SELinux
* Smack
* Tomoyo Linux
* Linux PAM

* Device drivers
* 802.11
* graphics
* Raw device

* initramfs
* KernelCare
* kexec
* kGraft
* kpatch
* Ksplice

Variants|

* Mainline
* Linux kernel
* Linux-libre
* High-performance computing
* INK
* Compute Node Linux
* SLURM
* Real-time computing
* RTLinux
* RTAI
* Xenomai
* PREEMPT_RT
* MMU-less
* μClinux
* PSXLinux

| Virtualization|

* Hypervisor
* KVM
* Xen
* OS-level virtualization
* Linux-VServer
* Lguest
* LXC
* OpenVZ
* Other
* L4Linux
* User-mode Linux
* MkLinux
* coLinux

|

Adoption|

| Range
of use|

* Desktop
* Embedded
* Gaming
* Thin client:
* LTSP
* Server:
* LAMP
* LYME-LYCE
* Devices

|

Adopters|

* List of Linux adopters

* Linux portal
* Free and open-source software portal
* Category

* v
* t
* e

Operating systems

General|

* Comparison
* Forensic engineering
* History
* List
* Timeline
* Usage share
* User features comparison

Variants|

* Disk operating system
* Distributed operating system
* Embedded operating system
* Hobbyist operating system
* Just enough operating system
* Mobile operating system
* Network operating system
* Object-oriented operating system
* Real-time operating system
* Supercomputer operating system

Kernel|

| Architectures|

* Exokernel
* Hybrid
* Microkernel
* Monolithic
* Multikernel
* vkernel
* Rump kernel
* Unikernel

|

Components|

* Device driver
* Loadable kernel module
* User space and kernel space

Process management|

| Concepts|

* Computer multitasking (Cooperative, Preemptive)
* Context switch
* Interrupt
* IPC
* Process
* Process control block
* Real-time
* Thread
* Time-sharing

|

Scheduling
algorithms|

* Fixed-priority preemptive
* Multilevel feedback queue
* Round-robin
* Shortest job next

Memory management,
resource protection|

* Bus error
* General protection fault
* Memory paging
* Memory protection
* Protection ring
* Segmentation fault
* Virtual memory

Storage access,
file systems|

* Boot loader
* Defragmentation
* Device file
* File attribute
* Inode
* Journal
* Partition
* Virtual file system
* Virtual tape library

Supporting concepts|

* API
* Computer network
* HAL
* Live CD
* Live USB
* Shell
* CLI
* User interface
* PXE

*[v]: View this template
*[t]: Discuss this template
*[e]: Edit this template