词条 | Linux kernel interfaces |
释义 |
}} 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 APIThe 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 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.[4] At the same time, Linux kernel developers have historically been conservative and meticulous about introducing new system calls.{{citation needed|date=November 2014}} 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.[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] {{Anchor|System Call Interface|SCI}} System Call Interface of the Linux kernelSystem 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 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.[8][9][10][11] The C standard libraryThe 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.
Additions to POSIXAs in other Unix-like systems, additional capabilities of the Linux kernel exist that are not part of POSIX:
Further libraries
Linux ABI{{Expert needed|Free and open-source software|ex2=Software|ex3=Computing|reason=This section mostly ignores the kernel-userspace ABI (that is very real and important thing) and jumps into userspace-to-userspace APIs|date=February 2018}}{{Main article|x32 ABI|Linux Standard Base}}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 vendor (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. End-users are in fact not all interested in the Linux API (or the Windows API), but in the ABIs. In-kernel APIsThere 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] In-kernel ABIsSince there are no stable in-kernel APIs, there cannot be stable in-kernel ABIs.[16] Abstraction APIsFor 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:
See also{{Portal|Linux}}
References1. ^1 {{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=}} 2. ^{{cite web |url=http://www.freedesktop.org/wiki/Software/libevdev/ |title=libevdev |publisher=freedesktop.org}} 3. ^{{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}} 4. ^{{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.}} 5. ^{{cite web |url=https://lwn.net/Articles/430598/ |title=Choosing between portability and innovation |publisher=LWN.net |date=2011-03-02}} 6. ^{{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 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. ^{{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}} 8. ^{{cite web |url=http://www.linux-magazine.com/Issues/2014/165/Kernel-News |title=System Call Organization}} 9. ^{{cite web |url=https://lkml.org/lkml/2014/2/27/571 |title= Making a universal list of syscalls? |publisher=LKML |date=2014-02-27}} 10. ^{{cite web |url=https://lwn.net/Articles/585415/ |title=Flags as a system call API design pattern |publisher=LWN.net |date=2014-02-12}} 11. ^{{cite web |url=https://lwn.net/Articles/446528/ |title=On vsyscalls and the vDSO |publisher=LWN.net |date=2011-06-08}} 12. ^{{cite web |url=https://lkml.org/lkml/2014/7/17/145 |title=[PATCH, RFC] random: introduce getrandom(2) system call |publisher=LKML |date=2014-07-17}} 13. ^{{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 }} 14. ^{{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}} 15. ^{{cite web|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/stable-api-nonsense.rst |title=The Linux Kernel Driver Interface}} 16. ^{{cite web|url=http://abi-laboratory.pro/tracker/timeline/linux/ | title=Analysis of ABI changes in the Linux kernel |publisher=Andrey Ponomarenko's ABI laboratory|date=2016-03-15}} External links
1 : Interfaces of the Linux kernel |
随便看 |
|
开放百科全书收录14589846条英语、德语、日语等多语种百科知识,基本涵盖了大多数领域的百科知识,是一部内容自由、开放的电子版国际百科全书。