The Linux kernel provides multiple interfaces to user-space applications that are used for varying purposes and that have varying properties by design. There are two types of application programming interface (API) in the Linux kernel 

 the "kernel–user space" API; and
 the "kernel internal" API.

Linux 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. 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. 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. People such as Lennart Poettering openly advocate to prefer the Linux API over the POSIX API, where this offers advantages.

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.

System Call Interface of the Linux kernel
System Call Interface is the denomination for the entirety of all implemented and available system calls in a kernel. Various subsystems, such as the Direct Rendering Manager (DRM), define their own system calls and the entirety is called 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.

The C standard library 

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

Additions to POSIX 
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
 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
 memfd was proposed by the kdbus developers
 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.

Further libraries 
 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 

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.

In-kernel APIs 
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.

In-kernel ABIs 
Since there are no stable in-kernel APIs, there cannot be stable in-kernel ABIs.

Abstraction APIs 

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.

See also 

 The Linux Programming Interface by Michael Kerrisk
 Semaphore (programming)
 system call is a function to facilitate programs to request services from the kernel
 
 netlink socket family used for IPC between kernel and user space processes, designed as the successor of ; 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

References

External links 
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
리눅스 커널은 설계에 따라 다양한 목적들과 다양한 속성들에 사용되는 사용자 공간 애플리케이션에 여러 인터페이스들을 제공한다. 리눅스 커널에는 두 종류의 API가 존재하는데 "커널 사용자 공간" API와 "커널 내부" API가 그것이다.

리눅스 API 

리눅스 API는 커널 사용자 공간 API로서, 사용자 공간에서 프로그램들이 리눅스 커널의 시스템 자원들과 서비스들에 접근할 수 있게 한다. 이것은 리눅스 커널의 시스템 호출 인터페이스와 GNU C 라이브러리(glibc)에 있는 서브루틴들로 이루어진다. 리눅스 API의 개발의 초점은 POSIX에서 정의된 명세들의 사용 가능한 특징들(POSIX에서 정의되지 않은 추가적인 특징들을 구현하는 커널 사용자 공간 API처럼 합리적으로 호환되고 탄탄하며 기준에 맞고 또한 POSIX에서 정의되지 않은 추가적인 특징들을 제공하는)을 제공하는 것이었다.

리눅스 API는 원한다면 몇 십년 동안 안정적이고 고장나지 않은 채로 유지된다; 이 안정성은 소스 코드의 이식 가능함을 보장한다. 동시에 리눅스 커널 개발자들은 역사적으로 새로운 시스템 호출들을 도입하는 것에 대해 보수적이고 꼼꼼한 경향이 있다.

더 사용 가능한 자유-오픈 소스 소프트웨어는 POSIX API로 쓰인다. 훨씬 많은 개발자들이 비교적으로 POSIX에 비해 리눅스 커널로 흘러들어왔기 때문에 리눅스 커널과 이것의 API는 추가적인 특징들로 주장되어 왔다. 이러한 추가적인 특징들이 기술적인 이점을 제공하는 한 리눅스 API로 프로그래밍 하는 것은 POSIX-API보다 선호되어 왔다. 잘 알려진 현재 예시들은 udev, systemd 그리고 Weston이 있다. 레네트 포터링 같은 사람들은 공개적으로 POSIX API에 대해 리눅스 API를 선호하였다.

리눅스 커널의 시스템 호출 인터페이스 
시스템 호출 인터페이스는 커널에서 모든 구현과 사용 가능한 모든 시스템 호출 전체를 위한 명칭이다. 다양한 서브시스템들은 자신의 시스템 호출을 정의하며 전체는 시스템 호출 인터페이스라고 불린다.

리눅스 커널 시스템 호출들의 조직과 관련된 다양한 이슈들은 공개적으로 논의되고 있다. 이슈들은 여러 사람들에 의해 지적되고 있다.

C 표준 라이브러리 

GNU C 라이브러리는 리눅스 커널의 시스템 호출들을 감싼다; 리눅스 커널 시스템 호출 인터페이스와 glibc의 조합이 리눅스 API를 만든다.
 GNU C 라이브러리 (glibc)
 임베디드 GNU C 라이브러리
 uClibc
 klibc
 Newlib
 musl
 dietlibc
 libbionic 그리고 libhybris

POSIX에 대한 추가 
다른 유닉스 계열 시스템처럼, POSIX가 아닌 곳에서도 추가적인 역량들이 존재한다.
 cgroups 서브시스템, 이것이 도입한 시스템 호출들 그리고 libcgroup
 직접 렌더링 관리자의 시스템 호출, 특히 명령어 서브미션을 위한 드라이버 용 ioctls는 POSIX 명세의 한 부분이 아니다.
 고급 리눅스 사운드 아키텍처는 시스템 호출을 설정할 수 있으며, 이것은 POSIX 명세의 한 부분이 아니다.
 시스템 호출 futex (빠른 사용자 공간 뮤텍스), epoll, splice, dnotify, fanotify, 그리고 inotify 는 지금까지 리눅스 커널 전용이다.
 시스템 호출 getrandom 는 리눅스 3.17에서 도입되었다.
 memfd 는 kdbus 개발자들에 의해 제안되었다.
 memfd_create 는 리눅스 3.17에서 주류가 되었다.
 readahead 는 파일 "read-ahead"를 페이지 캐시로 초기화한다.
DRM는 잘 정의되고 성능에 맞는 자유 그리고 오픈 소스 그래픽 장치 드라이버의 개발과 구현에서 최고의 지위를 가져왔다. DRM은 리눅스를 위해 개발되었으며, 다른 운영 체제에도 복사되었다.

리눅스 ABI 

리눅스 API라는 용어는 커널 사용자 공간 ABI와 관련 있다. 기계어에서 응용 프로그램 이진 인터페이스는 컴파일된 바이너리와 관련 있다. 이러한 ABI 어느 것이라도 명령어 집합과 관련된다. 유용한 ABI를 정의하고 안정적으로 유지하는 것은 리눅스 커널 개발자들이나 GNU C 라이브러리의 개발자들의 책임이 아니라, 리눅스 배포자들과 독립적인 소프트웨어 벤더들의 책임이다.

ABI는 모든 명령어 집합을 위해 정의되며, 이것으로는  x86, x86-64, MIPS, ARMv7-A (32비트), ARMv8-A (64비트) 등이 있다. 이것은 또한 지원된다면 엔디안과 함께 정의된다.

리눅스 ABI는 반드시 소프트웨어를 다른 컴파일러와 컴파일할 수 있어야 한다. 자유-오픈 소스 소프트웨어인 컴파일러들로는 GNU 컴파일러 모음과 LLVM/클랭이 있다.

최종 사용자들은 사실 리눅스 API에는 관심이 없고 ABI들에 관심이 있다.

커널 내부 API 
수많은 커널 내부 API들은 모든 서브시스템들이 다른 서브시스템들과 상호작용하기 위해 존재한다. 이것들은 꽤 안정적이지만 안정성에 대한 보장은 없다.

리눅스 커널은 모놀리딕 커널이므로 장치 드라이버들은 커널 구성 요소이다. 회사들이 자신의 장치 드라이버들을 유지 보수하는 짐을 덜어주기 위해서 장치 드라이버를 위한 안정적인 API들이 반복적으로 요청된다. 리눅스 커널 개발자들은 반복적으로 장치 드라이버들에 대한 안정적인 커널 내부 API를 보장하는 것을 거부한다. 이러한 것을 보장하는 것은 과거 리눅스 커널의 개발을 흔들었으며 미래에도 그럴 것으로 여겨져 오고 있다. 그러므로 리눅스 커널은 자진해서 안정적인 커널 내부 API를 갖지 않는다.

커널 내부 ABI 
안정적인 커널 내부 API가 없기 때문에, 안정적인 커널 내부 ABI도 존재할 수 없다.

같이 보기 
 리눅스 프로그래밍 인터페이스
 세마포어
 시스템 호출 : 이것은 프로그램이 커널에서 서비스를 요청하는 것을 가능하게 하는 기능이다.
 파일 서술자
 넷링크
 윈도우 API : 마이크로소프트 윈도우 운영 체제들에서 사용 가능한 다양한 API들에 대한 글
 windows.h : C를 위한 헤더파일로서, 윈도우 API에서의 모든 함수들을 위한 선언들을 포함한다.
 와인 : 리눅스와 마이크로소프트 윈도우 용 프로그램 사이의 호환 계층
 libhybris – 리눅스와 안드로이드 용으로 쓰인 프로그램 사이의 호환 계층

각주

외부 링크 
 The API of Linux kernel 2.6.20 – sadly no current version available
 The Linux Programming Interface
 Interactive Linux kernel map with main API functions and structures
 Linux Device Drivers by Jonathan Corbet, Greg Kroah-Hartman and Alessandro Rubini, 3rd edition
 Linux Kernel Linked List Explained 
 TLPI: API changes, Linux API changes since The Linux Programming Interface was released in 2010