Interfaces del kernel de Linux

El kernel de Linux proporciona múltiples interfaces para código en espacio de usuario y en modo kernel que se utilizan para diversos propósitos y que tienen diferentes propiedades según el diseño. Hay dos tipos de interfaz de programación de aplicaciones (API) en el kernel de Linux:

1. la API de "espacio-usuario"; y
2. la API "ancla interna".

API de Linux

La API de Linux incluye la API del espacio de usuario del kernel, que permite que el código en el espacio del usuario acceda a los recursos y servicios del sistema del kernel de Linux. Se compone de la interfaz de llamada al sistema del kernel de Linux y las subrutinas de la biblioteca estándar C. El objetivo del desarrollo de la API de Linux ha sido proporcionar las características utilizables de las especificaciones definidas en POSIX de una manera que sea razonablemente compatible, robusta y eficaz, y proporcionar características útiles adicionales no definidas en POSIX, al igual que las API del espacio de usuario del kernel de otros sistemas que implementan la API POSIX, también proporcionan características adicionales no definidas en POSIX.

La API de Linux, por elección propia, se ha mantenido estable a lo largo de décadas mediante una política de no introducir cambios importantes; esta estabilidad garantiza la portabilidad del código fuente. Al mismo tiempo, los desarrolladores del kernel de Linux históricamente han sido conservadores y meticulosos a la hora de introducir nuevas llamadas al sistema.

Gran parte del software gratuito y de código abierto disponible está escrito para la API POSIX. Dado que fluye mucho más desarrollo hacia el kernel de Linux en comparación con otras combinaciones de kernel y biblioteca estándar C compatibles con POSIX, el kernel de Linux y su API se han aumentado con características adicionales. La programación para la API completa de Linux, en lugar de solo la API POSIX, puede proporcionar ventajas en los casos en que esas características adicionales sean útiles. Ejemplos actuales muy conocidos son udev, systemd y Weston. Personas como Lennart Poettering abogan abiertamente por preferir la API de Linux a la API POSIX, donde esto ofrece ventajas.

En FOSDEM 2016, Michael Kerrisk explicó algunos de los problemas percibidos con la API de espacio de usuario del kernel de Linux, y describió que contiene múltiples errores de diseño al no ser extensible, no mantenible, demasiado complejo, de propósito limitado, en violación de las normas e inconsistente. La mayoría de esos errores no se pueden corregir porque hacerlo rompería la ABI que el kernel presenta al espacio del usuario.

Interfaz de llamada al sistema del kernel de Linux

La interfaz de llamadas al sistema de un kernel es el conjunto de todas las llamadas al sistema implementadas y disponibles en un kernel. En el kernel de Linux, varios subsistemas, como Direct Rendering Manager (DRM), definen sus propias llamadas al sistema, todas las cuales forman parte de la interfaz de llamadas del sistema.

Se están discutiendo públicamente varios problemas con la organización de las llamadas al sistema del kernel de Linux. Andy Lutomirski, Michael Kerrisk y otros han señalado problemas.

La biblioteca estándar de C

Una biblioteca estándar de C para Linux incluye envoltorios para las llamadas al sistema del kernel de Linux; la combinación de la interfaz de llamada al sistema del kernel de Linux y una biblioteca estándar de C es lo que construye la API de Linux. Algunas implementaciones populares de la biblioteca estándar C son

• glibc
• uClibc
• klibc
• Newlib
• musl
• Dietlibc
• libbionic and libhybris

Adiciones a POSIX

Al igual que en otros sistemas tipo Unix, existen capacidades adicionales del kernel de Linux que no forman parte de POSIX:

• cgroups subsistema, el sistema lo llama introducir y libcgroup
• El sistema llama al Administrador de Rendering Directo, especialmente los ioctls conductor-privados para la presentación del comando, son no parte de las especificaciones POSIX.
• Arquitectura de sonido avanzada de Linux podría ser sistema conjunto llamadas, que no son parte de las especificaciones POSIX
• El sistema llama futex (rápido mutex del espacio de usuario), epoll, splice, dnotify, fanotify, y inotify han sido exclusivos del núcleo Linux hasta ahora.
• La llamada del sistema getrandom se introdujo en la versión 3.17 del kernel de Linux
• memfd fue propuesto por los desarrolladores kdbus
  • memfd_create se fusionó en la línea principal del kernel de Linux en versión del kernel 3.17
• readahead inicia un archivo "read-ahead" en el cache de página

DRM ha sido fundamental para el desarrollo y las implementaciones de controladores de dispositivos gráficos de código abierto, gratuitos y de alto rendimiento, bien definidos y sin los cuales no habría ninguna aceleración de renderizado disponible, solo los controladores 2D estarían disponibles en el servidor X.Org. . DRM se desarrolló para Linux y desde entonces también se ha adaptado a otros sistemas operativos.

Más bibliotecas

• libdrm (para Direct Rendering Manager)
• libnl (La suite libnl es una colección de bibliotecas que proporcionan API a las interfaces de kernel basadas en protocolos de redlink.)
• libevdev (para evdev)
• libasound (Advanced Linux Sound Architecture)

ABI de Linux

El término ABI de Linux se refiere a una ABI de espacio de usuario-kernel. La interfaz binaria de la aplicación se refiere a los binarios compilados, en código de máquina. Por lo tanto, cualquier ABI de este tipo está vinculada al conjunto de instrucciones. Definir una ABI útil y mantenerla estable es menos responsabilidad de los desarrolladores del kernel de Linux o de los desarrolladores de la biblioteca GNU C, y más una tarea para las distribuciones de Linux y los proveedores de software independientes (ISV) que desean vender y brindar soporte para sus software propietario como binarios solo para una única ABI de Linux, en lugar de admitir múltiples ABI de Linux.

Se debe definir una ABI para cada conjunto de instrucciones, como x86, x86-64, MIPS, ARMv7-A (32 bits), ARMv8-A (64 bits), etc. con endianidad, si ambas son compatibles.

Debería poder compilar el software con diferentes compiladores según las definiciones especificadas en la ABI y lograr una compatibilidad binaria total. Los compiladores que son software gratuitos y de código abierto son, p. Colección de compiladores GNU, LLVM/Clang.

API integradas en el kernel

Existen muchas API internas del kernel, que permiten que los subsistemas del kernel interactúen entre sí. Estos se mantienen bastante estables, pero no hay garantía de estabilidad. Una API interna del kernel se puede cambiar cuando tal necesidad lo indiquen nuevas investigaciones o conocimientos; todas las modificaciones y pruebas necesarias deben ser realizadas por el autor.

El kernel de Linux es monolítico, por lo tanto, los controladores de dispositivos son componentes del kernel. Para aliviar la carga de las empresas que mantienen sus controladores de dispositivos (patentados) fuera del árbol principal del kernel, se han solicitado repetidamente API estables para los controladores de dispositivos. Los desarrolladores del kernel de Linux han negado repetidamente que garanticen API estables en el kernel para los controladores de dispositivos. Garantizar esto habría frenado el desarrollo del kernel de Linux en el pasado y lo seguirá haciendo en el futuro y, debido a la naturaleza del software gratuito y de código abierto, no es necesario. Ergo, por elección propia, el kernel de Linux no tiene una API interna estable.

ABI en el kernel

Dado que no existen API estables en el kernel, no puede haber ABI estables en el kernel.

API de abstracción

En muchos casos de uso, la API de Linux se considera de nivel demasiado bajo, por lo que se deben utilizar API de mayor abstracción. Las API de nivel superior deben implementarse además de las API de nivel inferior. Ejemplos:

• Implementación de las especificaciones OpenGL y Vulkan en los controladores gráficos patentados de Linux y la implementación gratuita y de código abierto en Mesa.
• Implementación de la especificación OpenAL.
• Simple DirectMedia Capa: API de abstracción para entrada/sonido/etc. disponible para muchos sistemas operativos.
• Multimedia simple y rápido Biblioteca: como arriba.