Linux kernel interfaces

[3] It is composed of the system call interface of the Linux kernel and the subroutines in the C standard library.

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.

[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.

Some popular implementations of the C standard library are As in other Unix-like systems, additional capabilities of the Linux kernel exist that are not part of POSIX: 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.

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 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.

Linux API, Linux ABI, and in-kernel APIs and ABIs
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 GNU C Library is a wrapper around the Linux kernel system call interface.
The Linux API and the Linux ABI
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.