API Linux, ABI Linux et API et ABI intégrées au noyau Le noyau Linux offre de multiples interfaces au code en espace utilisateur et au code en mode noyau. Ces interfaces peuvent...
Worldlex WikiContenu en francaisLecture gratuite
API Linux, ABI Linux et API et ABI intégrées au noyau
L'API Linux comprend l'API noyau - espace utilisateur, qui permet au code exécuté dans l'espace utilisateur d'accéder aux ressources et services du noyau Linux. Elle est composée de l'interface d'appels système du noyau Linux et des sous-programmes de la bibliothèque standard C. Le développement de l'API Linux a été axé sur la fourniture des fonctionnalités utiles des spécifications POSIX, de manière compatible, robuste et performante, ainsi que sur l'ajout de fonctionnalités utiles non définies dans POSIX, à l'instar des API noyau - espace utilisateur d'autres systèmes implémentant l'API POSIX.
L'API Linux a été délibérément maintenue stable au fil des décennies grâce à une politique de non-introduction de changements incompatibles ; cette stabilité garantit la portabilité du code source . Parallèlement, les développeurs du noyau Linux ont toujours fait preuve de prudence et de méticulosité quant à l'introduction de nouveaux appels système.logiciels libres et open source sont écrits pour l'API POSIX. Le développement étant bien plus important pour le noyau Linux que pour les autres combinaisons noyau/bibliothèque standard C conformes à POSIX, le noyau Linux et son API ont été enrichis de fonctionnalités supplémentaires. Programmer pour l'API Linux complète, plutôt que pour la seule API POSIX, peut s'avérer avantageux lorsque ces fonctionnalités supplémentaires sont utiles. udev , systemd et Weston en sont des exemples bien connus . Des personnes comme Lennart Poettering préconisent ouvertement de privilégier l'API Linux à l'API POSIX lorsque celle-ci présente des avantages.
Lors de la conférence FOSDEM 2016, Michael Kerrisk a exposé certains problèmes perçus concernant l'API espace utilisateur du noyau Linux. Il a notamment décrit comment elle comporte de multiples erreurs de conception : elle est non extensible, difficile à maintenir, excessivement complexe, d'utilité limitée, non conforme aux normes et incohérente. La plupart de ces erreurs sont irrémédiables, car leur correction compromettrait l'ABI que le noyau présente à l'espace utilisateur.
appels système implémentés et disponibles dans ce noyau. Sous Linux, différents sous-systèmes, comme le gestionnaire de rendu direct (DRM), définissent leurs propres appels système, qui font tous partie de l'interface d'appels système.
Divers problèmes liés à l'organisation des appels système du noyau Linux font l'objet de discussions publiques. Ces problèmes ont été soulevés par Andy Lutomirski, Michael Kerrisk et d'autres.
La bibliothèque standard C
La bibliothèque GNU C est une interface simplifiée autour de l'interface d'appel système du noyau Linux.
Une bibliothèque standard C pour Linux inclut des interfaces pour les appels système du noyau Linux ; la combinaison de l’interface d’appel système du noyau Linux et d’une bibliothèque standard C constitue l’API Linux. Voici quelques implémentations courantes de la bibliothèque standard C :
Bien que le paysage évolue, parmi ces options, glibc reste l'implémentation la plus populaire, au point que beaucoup la considèrent comme la valeur par défaut et l'équivalent de libc.
Ajouts à POSIX
Comme dans d'autres systèmes de type Unix , le noyau Linux possède des fonctionnalités supplémentaires qui ne font pas partie de POSIX :
Les appels système du gestionnaire de rendu direct , en particulier les ioctls privés au pilote pour la soumission de commandes, ne font pas partie des spécifications POSIX.
Les appels système futex(mutex rapide en espace utilisateur), epoll, splice, dnotify, fanotify, et inotifyont été jusqu'à présent exclusifs au noyau Linux.
L'ABI Linux est une interface noyau-espace utilisateur. Étant une interface de code machine , l'ABI Linux est liée au jeu d'instructions . Définir une ABI utile et la maintenir stable relève moins de la responsabilité des développeurs du noyau Linux ou de la bibliothèque GNU C, que des distributions Linux et des éditeurs de logiciels indépendants (ISV) qui souhaitent vendre et assurer le support de leurs logiciels propriétaires sous forme de binaires compatibles uniquement avec une seule ABI Linux, plutôt que de prendre en charge plusieurs ABI Linux.
Une ABI doit être définie pour chaque jeu d'instructions, tel que x86 , x86-64 , MIPS , ARMv7-A (32 bits), ARMv8-A (64 bits), etc. avec l' endianness , si les deux sont pris en charge.
Il devrait être possible de compiler le logiciel avec différents compilateurs en fonction des définitions spécifiées dans l'ABI et d'obtenir une compatibilité binaire totale. Parmi les compilateurs libres et open source, on peut citer par exemple GNU Compiler Collection et LLVM / Clang .
API intégrées au noyau
Il existe de nombreuses API internes au noyau, permettant aux sous-systèmes du noyau de communiquer entre eux. Bien que leur stabilité soit maintenue, elle n'est pas garantie. Une API interne au noyau peut être modifiée si de nouvelles recherches ou observations le justifient ; toutes les modifications et tous les tests nécessaires doivent être effectués par son auteur.
Le noyau Linux étant monolithique, les pilotes de périphériques en sont des composants. Afin d'alléger la charge de maintenance (parfois propriétaire) des pilotes de périphériques par les entreprises en dehors de l'arbre principal du noyau, des API stables pour ces pilotes ont été demandées à plusieurs reprises. Les développeurs du noyau Linux ont systématiquement refusé de garantir des API stables au sein du noyau. Une telle garantie aurait freiné le développement du noyau Linux par le passé et le freinerait encore à l'avenir. De plus, compte tenu de la nature des logiciels libres et open source, elle n'est pas nécessaire. Par conséquent, le noyau Linux ne dispose pas, par choix, d'API stable au sein de son noyau.
ABI intégrés au noyau
Puisqu'il n'existe pas d'API stables au sein du noyau, il ne peut pas exister d'ABI stables au sein du noyau.
API d'abstraction
OpenGL est en effet une API d'abstraction permettant d'utiliser divers GPU de plusieurs fournisseurs sans avoir besoin de programmer spécifiquement pour chacun d'eux.Cependant, l'implémentation de la spécification OpenGL est exécutée sur le processeur dans le contexte du système d'exploitation. L'un des objectifs de conception de Vulkan était de réduire la charge du « pilote graphique », c'est-à-dire l'implémentation de l'API graphique.
Dans de nombreux cas d'utilisation, l'API Linux est considérée comme trop bas niveau ; il est donc nécessaire d'utiliser des API de plus haut niveau d'abstraction. Ces API de plus haut niveau doivent être implémentées par-dessus les API de plus bas niveau. Exemples :
Implémentation des spécifications OpenGL et Vulkan dans les pilotes graphiques propriétaires Linux et l'implémentation libre et open source dans Mesa .
Worldlex Wiki 
