|
The Linux kernel provides several interfaces to user-space applications that are used for different purposes and that have different properties by design. There are two types of [[application programming interface]] (API) in the [[Linux kernel]] that are not to be confused: the "kernel–user space" API and the "kernel internal" API.
== {{Anchor|Linux API}}Linux API ==
}}</ref>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. ▼[[File:Linux API.svg|thumb|upright=1.5|The '''Linux API''' is composed out of the System Call Interface of the Linux kernel, the [[GNU C Library]] (by [[GNU]]), [[cgroups|libcgroup]],<ref name="libcgroup">{{cite web|url=https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/|title=ControlGroupInterface|last=|first=|date=|website=|publisher=[[freedesktop.org]]|archive-url=|archive-date=|dead-url=|access-date=}}</ref> [[Direct Rendering Manager|libdrm]], [[Advanced Linux Sound Architecture|libalsa]] and [[evdev|libevdev]]<ref name="libevdev">{{cite web |url=http://www.freedesktop.org/wiki/Software/libevdev/ |title=libevdev |publisher=[[freedesktop.org]]}}</ref> (by [[freedesktop.org]]).]]
[[File:Linux kernel API.svg|thumb|upright=1.5|Linux API vs. [[POSIX]] API]]
}}</ref>The Linux API, by choice, has been kept stable over the decades and never breaks; 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. {{citation needed|date=November 2014}}▼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.<ref>{{cite web
| url = http://www.linux.it/~rubini/docs/ksys/ksys.html
| title = Kernel System Calls
| date = 2006-11-02 | accessdate = 2014-11-11
| author = Alessandro Rubini | website = linux.it
▲}}</ref> 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.
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.
The Linux API, by choice, has been kept stable over the decades and never breaks;{{Clarify|reason=Doesn't it mean backward compatibility? It worth to rewrite this part.|date=March 2019}} this stability guarantees the portability of [[source code]].<ref>{{cite web
| url = https://lkml.org/lkml/2012/12/23/75
| title = Re: [Regression w/ patch] Media commit causes user space to misbahave (was: Re: Linux 3.8-rc1)
| date = 2012-12-23 | accessdate = 2014-08-26
| author = Linus Torvalds | publisher = [[Linux kernel mailing list]]
| quote = If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs.
▲}}</ref> At the same time, Linux kernel developers have historically been conservative and meticulous about introducing new system calls.{{citation needed|date=November 2014}}
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. <ref>{{cite web|url=https://archive.fosdem.org/2016/schedule/event/design_linux_kernel_api/|title=How to design a Linux kernel API|author=[[Michael Kerrisk]]|first=|date=2016-01-31|website=|archive-url=|archive-date=|dead-url=|accessdate=2016-02-04}}</ref>▼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|date=July 2014}} 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 (software)|Weston]].<ref>{{cite web |url=https://lwn.net/Articles/430598/ |title=Choosing between portability and innovation |publisher=[[LWN.net]] |date=2011-03-02}}</ref> People such as [[Lennart Poettering]] openly advocate to prefer the Linux API over the POSIX API, where this offers advantages.<ref name="fosdem1">{{cite web|url=https://archive.fosdem.org/2011/interview/lennart-poettering.html |publisher=fosdem.org |title=Interview: Lennart Poettering - Lennart Poettering will give a talk about "Systemd: beyond init" at FOSDEM 2011.|year=2011 |accessdate=2014-06-16 |quote=''In fact, the way I see things the '''[[Linux kernel API|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!''}}</ref>
=== {{Anchor|System Call Interface|SCI}} System Call Interface of the Linux kernel=== ▼▲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.<ref>{{cite web|url=https://archive.fosdem.org/2016/schedule/event/design_linux_kernel_api/|title=How to design a Linux kernel API|author=[[Michael Kerrisk]]|first=|date=2016-01-31|website=|archive-url=|archive-date=|dead-url=|accessdate=2016-02-04}}</ref>
''System Call Interface'' is the denomination for the entirety of all implemented and available [[system calls ]] in a kernel. Various subsystems, such as e.g. 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.
▲=== {{Anchor|System Call Interface|SCI}} 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 e.g. 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.<ref>{{cite web |url=http://www.linux-magazine.com/Issues/2014/165/Kernel-News |title=System Call Organization}}</ref><ref>{{cite web |url=https://lkml.org/lkml/2014/2/27/571 |title= Making a universal list of syscalls? |publisher=[[LKML]] |date=2014-02-27}}</ref><ref>{{cite web |url=https://lwn.net/Articles/585415/ |title=Flags as a system call API design pattern |publisher=[[LWN.net]] |date=2014-02-12}}</ref><ref>{{cite web |url=https://lwn.net/Articles/446528/ |title=On vsyscalls and the vDSO |publisher=[[LWN.net]] |date=2011-06-08}}</ref>
=== The C standard library ===
[[File:Linux kernel System Call Interface and glibc.svg|thumb|upright=1.5|The [[GNU C Library]] is a wrapper around the system calls of the Linux kernel; the combination of the Linux kernel System Call Interface and glibc is what builds the Linux API.]]
The [[GNU C Library]] is a wrapper around the system calls of the Linux kernel; the combination of the Linux kernel System Call Interface and glibc is what builds the Linux API.
* [[GNU C Library]] (glibc)
* [[Embedded GLIBC]]
* [[uClibc]]
* [[klibc]]
* [[Newlib]]
* [[musl]]
* [[dietlibc]]
* [[Bionic (software)|libbionic]] and [[Hybris (software)|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<ref name="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 <code>[[futex]]</code> (fast userspace mutex), <code>[[epoll]]</code>, <code>[[splice (system call)|splice]]</code>, <code>[[dnotify]]</code>, <code>[[fanotify]]</code>, and <code>[[inotify]]</code> have been exclusive to the Linux kernel so far.
* The system call <code>[[getrandom]]</code> was introduced in version 3.17 of the [[Linux kernel mainline]]<ref>{{cite web |url=https://lkml.org/lkml/2014/7/17/145 |title=[PATCH, RFC] random: introduce getrandom(2) system call |publisher=[[Linux kernel mailing list|LKML]] |date=2014-07-17}}</ref>
* <code>memfd</code> was proposed by the kdbus developers
* <code>[[memfd]]</code> was proposed by the kdbus developers<ref>{{cite web |url=https://github.com/gregkh/kdbus/blob/master/memfd.c |archive-url=https://archive.is/20140422172420/https://github.com/gregkh/kdbus/blob/master/memfd.c |dead-url=yes |archive-date=2014-04-22 |title=memfd.c }}</ref>
** <code>[[memfd_create]]</code> was merged into the Linux kernel mainline in kernel version 3.17
* <code>[[readahead]]</code> initiates a file "read-ahead" into page cache
[[Direct Rendering Manager|DRM]] has been paramount for the development and implementations of well-defined and performant [[Free and open-source graphics device driver#Software architecture|free and open-source graphics device drivers]] without which no rendering acceleration would be available at all, or even worse, 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.<ref>{{cite web |url=https://www.phoronix.com/scan.php?page=news_item&px=MTYzNTQ |title=NetBSD 7.0 Will Finally Have DRM/KMS Drivers |publisher=[[Phoronix]] |date=2014-03-19}}</ref>
=== 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]])
* …
| 