Interfejsy jądra Linux - Linux kernel interfaces

Image
Linux API, Linux ABI oraz interfejsy API i ABI w jądrze

Jądro systemu Linux zapewnia kilka interfejsów do aplikacji w przestrzeni użytkownika, które są używane do różnych celów i mają różne właściwości zgodnie z projektem. Istnieją dwa typy interfejsu programowania aplikacji (API) w jądrze Linuksa , których nie należy mylić: API „jądro-przestrzeń użytkownika” i API „wewnętrzne jądro”.

Interfejs API Linuksa

Image
Linux API składa się z systemu Call Interface jądra Linux, biblioteki GNU C (przez GNU ), libcgroup , libdrm , libalsa i libevdev (przez freedesktop.org ).
Image
Linux API a POSIX API

Linux API to interfejs API przestrzeni jądra i użytkownika, który umożliwia programom w przestrzeni użytkownika dostęp do zasobów systemowych i usług jądra systemu Linux. Składa się z interfejsu wywołań systemowych jądra Linux i podprogramów w bibliotece GNU C (glibc). Celem rozwoju API Linuksa było zapewnienie użytecznych funkcji specyfikacji zdefiniowanych w POSIX w sposób, który jest w miarę kompatybilny, solidny i wydajny, oraz dostarczenie dodatkowych przydatnych funkcji, które nie są zdefiniowane w POSIX, podobnie jak jądro – Interfejsy API przestrzeni użytkownika innych systemów implementujących POSIX API również udostępniają dodatkowe funkcje, które nie są zdefiniowane w POSIX.

Linux API, z wyboru, był utrzymywany na stabilnym poziomie przez dziesięciolecia dzięki polityce niewprowadzania przełomowych zmian; ta stabilność gwarantuje przenośność kodu źródłowego . Jednocześnie twórcy jądra Linuksa byli historycznie konserwatywni i skrupulatni we wprowadzaniu nowych wywołań systemowych.

Wiele dostępnego bezpłatnego oprogramowania o otwartym kodzie źródłowym zostało napisane dla POSIX API. Ponieważ do jądra Linuksa wpływa o wiele więcej prac programistycznych w porównaniu z innymi kombinacjami jądra i standardowej biblioteki C, zgodnymi z POSIX, jądro Linuksa i jego API zostały rozszerzone o dodatkowe funkcje. O ile te dodatkowe funkcje zapewniają przewagę techniczną, programowanie dla Linux API jest preferowane w stosunku do POSIX-API. Dobrze znane obecne przykłady to udev , systemd i Weston . Ludzie tacy jak Lennart Poettering otwarcie opowiadają się za preferowaniem Linux API w stosunku do POSIX API, gdzie oferuje to korzyści.

Na FOSDEM 2016 Michael Kerrisk wyjaśnił niektóre z dostrzeżonych problemów z interfejsem API przestrzeni użytkownika jądra Linuksa, opisując, że zawiera wiele błędów projektowych, ponieważ jest nierozszerzalny, niemożliwy do utrzymania, nadmiernie złożony, o ograniczonym przeznaczeniu, z naruszeniem standardów i niespójnym . Większości z tych błędów nie można naprawić, ponieważ spowodowałoby to złamanie ABI, które jądro przedstawia w przestrzeni użytkownika.

Interfejs wywołań systemowych jądra Linux

Interfejs wywołań systemowych to określenie całości wszystkich zaimplementowanych i dostępnych wywołań systemowych w jądrze. Różne podsystemy, jak np. DRM, definiują własne wywołania systemowe, a całość nazywa się System Call Interface.

Publicznie dyskutowane są różne kwestie związane z organizacją wywołań systemowych jądra Linuksa. Na problemy wskazywali Andy Lutomirski, Michael Kerrisk i inni.

Biblioteka standardowa C

Image
Biblioteka GNU C jest owinięcie wokół jądra systemu Linux interfejs wywołania.

Biblioteka standardowa języka C jest owinięcie wokół wywołań systemowych jądra Linux; połączenie interfejsu wywołań systemowych jądra Linuksa i standardowej biblioteki C jest tym, co buduje API Linuksa.

Dodatki do POSIX

Podobnie jak w innych systemach uniksopodobnych, istnieją dodatkowe możliwości jądra Linux, które nie są częścią POSIX:

DRM był kluczowy dla rozwoju i implementacji dobrze zdefiniowanych i wydajnych sterowników urządzeń graficznych bezpłatnych i typu open source, bez których żadne przyspieszenie renderowania nie byłoby dostępne lub, co gorsza, tylko sterowniki 2D byłyby dostępne w X.Org Serwer . DRM został opracowany dla Linuksa i od tego czasu został przeniesiony również na inne systemy operacyjne.

Dalsze biblioteki

ABI dla Linuksa

Image
Linux API i Linux ABI
Główne artykuły: x32 ABI i Linux Standard Base

Termin Linux ABI odnosi się do ABI w przestrzeni jądra i użytkownika. Interfejs binarny zastosowanie dotyczy binarki w kodu maszynowego . Każdy taki ABI jest zatem powiązany z zestawem instrukcji . Zdefiniowanie użytecznego ABI i utrzymywanie go stabilnego jest w mniejszym stopniu obowiązkiem twórców jądra Linuksa lub twórców biblioteki GNU C, a bardziej zadaniem dystrybucji Linuksa i niezależnych dostawców oprogramowania (ISV), którzy chcą sprzedawać i zapewniać wsparcie dla swoich własnościowe oprogramowanie jako pliki binarne tylko dla takiego pojedynczego Linux ABI, w przeciwieństwie do obsługi wielu Linux ABI.

ABI musi być zdefiniowany dla każdego zestawu instrukcji, takiego jak x86 , x86-64 , MIPS , ARMv7-A (32-Bit), ARMv8-A (64-Bit) itp. z endianness , jeśli oba są obsługiwane.

Powinien być w stanie skompilować oprogramowanie z różnymi kompilatorami zgodnie z definicjami określonymi w ABI i osiągnąć pełną kompatybilność binarną. Kompilatory, które są darmowym oprogramowaniem o otwartym kodzie źródłowym to np. GNU Compiler Collection , LLVM / Clang .

W rzeczywistości nie wszyscy użytkownicy końcowi są zainteresowani Linuksowym API (lub Windows API), ale ABI.

Interfejsy API w jądrze

Istnieje wiele wewnętrznych interfejsów API dla wszystkich podsystemów, które mogą się ze sobą komunikować. Są one utrzymywane na dość stabilnym poziomie, ale nie ma gwarancji stabilności. W przypadku, gdy nowe badania lub spostrzeżenia sprawiają, że zmiana wydaje się korzystna, interfejs API jest zmieniany, wszystkie niezbędne przepisanie i testy muszą zostać wykonane przez autora.

Jądro Linuksa jest jądrem monolitycznym, dlatego sterowniki urządzeń są składnikami jądra. Aby zmniejszyć obciążenie firm utrzymujących swoje (zastrzeżone) sterowniki urządzeń poza drzewem, wielokrotnie proszono o stabilne interfejsy API dla sterowników urządzeń. Twórcy jądra Linuksa wielokrotnie zaprzeczali gwarantowaniu stabilnych interfejsów API w jądrze dla sterowników urządzeń. Zagwarantowanie tego zakłóciłoby rozwój jądra Linuksa w przeszłości i nadal byłoby w przyszłości, a ze względu na naturę wolnego i otwartego oprogramowania nie jest konieczne. Ergo, z wyboru, jądro Linuksa nie ma stabilnego interfejsu API w jądrze.

ABI w jądrze

Ponieważ nie ma stabilnych interfejsów API w jądrze, nie mogą istnieć stabilne interfejsy ABI w jądrze.

Abstrakcja API

Image
OpenGL jest rzeczywiście abstrakcyjnym API do korzystania z różnych procesorów graficznych wielu dostawców bez konieczności programowania dla każdego z nich.
Image
Ale implementacja specyfikacji OpenGL jest wykonywana na procesorze w kontekście działającego systemu operacyjnego. Jednym z celów projektowych Vulkan było zmniejszenie wydajności „sterownika graficznego”, tj. implementacji API graficznego.

W kilku przypadkach użycia Linux API jest uważany za zbyt niskopoziomowy i używane są API o wyższej abstrakcji. Takie oczywiście nadal muszą działać w oparciu o niskopoziomowe API Linuksa. Przykłady:

Zobacz też

  • Interfejs programowania Linux autorstwa Michaela Kerriska
  • Semafor (programowanie)
  • wywołanie systemowe  – to funkcja ułatwiająca programom żądanie usług z jądra
    • zdarzeniefd()
    • netlink  – rodzina gniazd używana do IPC pomiędzy procesami jądra i przestrzeni użytkownika, zaprojektowana jako następca ioctl ; Netlink został dodany przez Alana Coxa podczas opracowywania jądra Linuksa 1.3 jako interfejs sterownika znaków, aby zapewnić wiele dwukierunkowych łączy komunikacyjnych jądra i przestrzeni użytkownika. Następnie Alexey Kuznetsov rozszerzył go podczas opracowywania jądra Linuksa 2.1, aby zapewnić elastyczny i rozszerzalny interfejs przesyłania wiadomości do nowej zaawansowanej infrastruktury routingu. Od tego czasu gniazda Netlink stały się jednym z głównych interfejsów dostarczanych przez podsystemy jądra do aplikacji działających w przestrzeni użytkownika w systemie Linux. Współczesne sterowniki WNIC używają go do komunikacji z przestrzenią użytkownika.
  • Windows API  – artykuł o różnych API dostępnych w systemach operacyjnych Microsoft Windows
  • Wine  – warstwa kompatybilności pomiędzy Linuksem a programami napisanymi dla Microsoft Windows
  • libhybris – warstwa kompatybilności pomiędzy Linuksem a programami napisanymi na Androida

Bibliografia

Zewnętrzne linki