Linux kernel interfaces - Linux kernel interfaces

Image
Linux API, Linux ABI og in-core API'er og ABI'er

Linux-kernen giver flere grænseflader til brugerrumsprogrammer, der bruges til forskellige formål, og som har forskellige egenskaber ved design. Der er to typer applikationsprogrammeringsinterface (API) i Linux -kernen , der ikke skal forveksles: "kernel -user space" API og "kernel intern" API.

Linux API

Image
Den Linux API er sammensat ud af systemet Call-interface af Linux-kernen, den GNU C-bibliotek (af GNU ), libcgroup , libdrm , libalsa og libevdev (ved freedesktop.org ).
Image
Linux API vs POSIX API

Linux API er kernel -user space API, som giver programmer i brugerrum adgang til systemressourcer og tjenester i Linux -kernen. Det er sammensat af systemopkaldsgrænsefladen til Linux -kernen og underrutinerne i GNU C -biblioteket (glibc). Fokus for udviklingen af ​​Linux API har været at levere de anvendelige funktioner i specifikationerne defineret i POSIX på en måde, der er rimeligt kompatibel, robust og performant, og at levere yderligere nyttige funktioner, der ikke er defineret i POSIX, ligesom kernen - brugerplads -API'er for andre systemer, der implementerer POSIX API, indeholder også yderligere funktioner, der ikke er defineret i POSIX.

Linux API, efter eget valg, er blevet holdt stabil gennem årtierne gennem en politik om ikke at indføre brydende ændringer; denne stabilitet garanterer overførsel af kildekode . På samme tid har Linux -kerneudviklere historisk set været konservative og omhyggelige med at indføre nye systemopkald.

Meget tilgængelig gratis og open-source software er skrevet til POSIX API. Da så meget mere udvikling strømmer ind i Linux-kernen sammenlignet med de andre POSIX-kompatible kombinationer af kerne- og C-standardbibliotek, er Linux-kernen og dens API blevet udvidet med yderligere funktioner. For så vidt disse ekstra funktioner giver en teknisk fordel, foretrækkes programmering til Linux API frem for POSIX-API. Kendte aktuelle eksempler er udev , systemd og Weston . Folk som Lennart Poettering taler åbent for at foretrække Linux API frem for POSIX API, hvor dette giver fordele.

På FOSDEM 2016 forklarede Michael Kerrisk nogle af de opfattede problemer med Linux-kernens bruger-space API, idet han beskrev, at den indeholder flere designfejl ved at være ikke-udvidelig, uholdbar, alt for kompleks, af begrænset formål, i strid med standarder og inkonsekvent . De fleste af disse fejl kan ikke rettes, fordi det ville bryde den ABI, som kernen præsenterer for brugerrummet.

Systemopkaldsgrænseflade for Linux -kernen

System Call Interface er betegnelsen for alle implementerede og tilgængelige systemopkald i en kerne. Forskellige undersystemer, f.eks. DRM definerer deres egne systemopkald, og helheden kaldes System Call Interface.

Forskellige problemer med organiseringen af ​​Linux -kernesystemopkald diskuteres offentligt. Problemer er blevet påpeget af Andy Lutomirski, Michael Kerrisk og andre.

C -standardbiblioteket

Image
Den GNU C-bibliotek er en wrapper omkring Linux-kernen System Call Interface.

Et C -standardbibliotek er en indpakning omkring systemopkaldene til Linux -kernen; kombinationen af ​​Linux -kernen System Call Interface og et C -standardbibliotek er det, der bygger Linux API.

Tilføjelser til POSIX

Som i andre Unix-lignende systemer findes der yderligere muligheder i Linux-kernen, som ikke er en del af POSIX:

DRM har været altafgørende for udvikling og implementering af veldefinerede og performante gratis og open-source grafikdrivere, uden hvilke der overhovedet ikke ville være nogen gengivelsesacceleration, eller endnu værre, kun 2D-driverne ville være tilgængelige i X.Org Server . DRM blev udviklet til Linux, og er siden også blevet portet til andre operativsystemer.

Yderligere biblioteker

Linux ABI

Image
Linux API og Linux ABI
Hovedartikler: x32 ABI og Linux Standard Base

Udtrykket Linux ABI refererer til et kerne -brugerrum ABI. Den ansøgning binære grænseflade henviser til de kompilerede binære filer, i maskinkode . Enhver sådan ABI er derfor bundet til instruktionssættet . At definere en nyttig ABI og holde den stabil er mindre ansvaret for Linux -kerneudviklerne eller udviklerne af GNU C -biblioteket og mere opgaven for Linux -distributioner og uafhængige softwareleverandører (ISV'er), der ønsker at sælge og yde support til deres proprietær software som binære filer kun for sådan en enkelt Linux ABI, i modsætning til at understøtte flere Linux ABI'er.

En ABI skal defineres for hvert instruktionssæt, f.eks. X86 , x86-64 , MIPS , ARMv7-A (32-Bit), ARMv8-A (64-Bit) osv. Med endianness , hvis begge understøttes.

Det skal være i stand til at kompilere softwaren med forskellige kompilatorer mod definitionerne angivet i ABI og opnå fuld binær kompatibilitet. Kompilatorer, der er gratis og open source-software, er f.eks. GNU Compiler Collection , LLVM / Clang .

Slutbrugere er faktisk ikke alle interesserede i Linux API (eller Windows API), men i ABI'erne.

In-kernel API'er

Der er en masse kernel-interne API'er, som alle undersystemer kan interagere med hinanden. Disse holdes ret stabile, men der er ingen garanti for stabilitet. Hvis ny forskning eller indsigt får en ændring til at virke gunstig, ændres en API, al nødvendig omskrivning og test skal udføres af forfatteren.

Linux -kernen er en monolitisk kerne, derfor er enhedsdrivere kernekomponenter. For at lette byrden for virksomheder, der vedligeholder deres (proprietære) enhedsdrivere uden for træet, er der gentagne gange blevet anmodet om stabile API'er til enhedsdriverne. Linux-kerneudviklerne har gentagne gange nægtet at garantere stabile in-kernel API'er til enhedsdrivere. At garantere sådanne ville have forstyrret udviklingen af ​​Linux-kernen tidligere og ville stadig i fremtiden og på grund af gratis og open-source software ikke være nødvendig. Ergo har Linux-kernen efter eget valg ingen stabil in-kernel API.

ABI'er i kernen

Da der ikke er nogen stabile in-kernel API'er, kan der ikke være stabile in-kernel ABI'er.

Abstraktions -API'er

Image
OpenGL er virkelig en abstraktions -API til at gøre brug af forskellige GPU'er fra flere leverandører uden at skulle programmere for hver enkelt specifikt.
Image
Men implementeringen af ​​OpenGL-specifikationen udføres på CPU'en i forbindelse med det kørende operativsystem. Et designmål for Vulkan var at få "grafikdriveren", dvs. implementeringen af ​​grafik -API'en, til at gøre mindre.

I flere brugstilfælde betragtes Linux API som for lavt niveau, og højere abstraktions API'er bruges. Sådanne skal naturligvis stadig fungere oven på Linux-API'erne på lavt niveau. Eksempler:

Se også

  • Linux -programmeringsgrænsefladen af Michael Kerrisk
  • Semafor (programmering)
  • systemopkald  - er en funktion til at lette programmer til at anmode om tjenester fra kernen
    • eventfd ()
    • netlink  - socket -familie, der bruges til IPC mellem kerne- og brugerrumsprocesser, designet som efterfølgeren til ioctl ; Netlink blev tilføjet af Alan Cox under Linux-kernel 1.3-udvikling som en karakterdriver-grænseflade til at levere flere kerne- og brugerpladser tovejskommunikationsforbindelser. Derefter udvidede Alexey Kuznetsov den under Linux kernel 2.1 udvikling til at levere en fleksibel og udvidelig messaging -grænseflade til den nye avancerede routinginfrastruktur. Siden da er Netlink-sockets blevet en af ​​de vigtigste grænseflader, som kerneundersystemer leverer til brugerpladsapplikationer i Linux. Moderne WNIC- drivere bruger det til at kommunikere med brugerplads.
  • Windows API  - artikel om forskellige API tilgængelige på Microsoft Windows -operativsystemer
    • windows.h  - header -fil til programmeringssproget C, der indeholder deklarationer for alle funktionerne i Windows API
  • Wine  - et kompatibilitetslag mellem Linux og programmer skrevet til Microsoft Windows
  • libhybris - kompatibilitetslag mellem Linux og programmer skrevet til Android

Referencer

eksterne links