Interfaces del kernel de Linux

El núcleo de Linux ofrece múltiples interfaces para código en modo kernel y en espacio de usuario que se utilizan para distintos propósitos y que tienen distintas propiedades por diseño. Existen dos tipos de interfaz de programación de aplicaciones (API) en el núcleo de Linux:

1. la API de "espacio de usuario del núcleo"; y
2. la API "interna del kernel".

La API de Linux incluye la API de espacio de usuario-núcleo, que permite que el código en el espacio de usuario acceda a los recursos y servicios del sistema del núcleo de Linux. ^[3] Está compuesta por la interfaz de llamada del sistema del núcleo de Linux y las subrutinas en la biblioteca estándar de C. El foco 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 de alto rendimiento, y proporcionar características útiles adicionales no definidas en POSIX, al igual que las API de espacio de usuario-núcleo 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 las décadas mediante una política de no introducir cambios disruptivos; esta estabilidad garantiza la portabilidad del código fuente . ^[4] Al mismo tiempo, los desarrolladores del kernel de Linux han sido históricamente conservadores y meticulosos a la hora de introducir nuevas llamadas al sistema. ^{[ cita requerida ]}

Gran parte del software libre y de código abierto disponible está escrito para la API POSIX. Dado que se destina mucho más desarrollo al núcleo de Linux en comparación con otras combinaciones de núcleo y biblioteca estándar de C compatibles con POSIX, ^{[ cita requerida ]} el núcleo de Linux y su API se han ampliado 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 bien conocidos son udev , systemd y Weston . ^[5] Personas como Lennart Poettering abogan abiertamente por preferir la API de Linux sobre la API POSIX, donde esto ofrece ventajas. ^[6]

En FOSDEM 2016, Michael Kerrisk explicó algunos de los problemas percibidos con la API de espacio de usuario del núcleo Linux, describiendo que contiene múltiples errores de diseño al no ser extensible, no ser mantenible, ser excesivamente compleja, tener un propósito limitado, violar estándares e inconsistente. La mayoría de esos errores no se pueden corregir porque al hacerlo se rompería la ABI que el núcleo presenta al espacio de usuario. ^[7]

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

Se están debatiendo públicamente diversos problemas relacionados con la organización de las llamadas al sistema del núcleo de Linux. Andy Lutomirski, Michael Kerrisk y otros han señalado algunos problemas . ^{[8] [9] [10] [11]}

Una biblioteca estándar de C para Linux incluye contenedores para las llamadas del sistema del núcleo de Linux; la combinación de la interfaz de llamadas del sistema del núcleo 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 de C son

• glibc
• uClibc
• Clibc
• Nueva biblioteca
• Musulmán
• Dieta libc
• libionico y libhybris

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

• Subsistema cgroups , el sistema lo llama, lo introduce y libcgroup ^[1]
• Las llamadas al sistema del Direct Rendering Manager , especialmente los ioctl privados del controlador para el envío de comandos, no son parte de las especificaciones POSIX.
• La arquitectura avanzada de sonido de Linux podría establecer llamadas del sistema que no son parte de las especificaciones POSIX
• Las llamadas del sistema futex(mutex rápido de espacio de usuario), epoll, splice, , y han sido exclusivas del kernel de Linux hasta ahora dnotify.fanotifyinotify
• La llamada al sistema getrandomse introdujo en la versión 3.17 de la línea principal del kernel de Linux ^[12]
• memfdFue propuesto por los desarrolladores de kdbus ^[13]
  • memfd_createSe fusionó con la línea principal del kernel de Linux en la versión 3.17 del kernel.
• readaheadInicia una "lectura anticipada" de archivo en la caché de la página.

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

• libdrm (para el administrador de renderizado directo )
• libnl (La suite libnl es una colección de bibliotecas que proporcionan API para interfaces de kernel de Linux basadas en el protocolo netlink).
• libevdev (para evdev )
• libasound ( Arquitectura avanzada de sonido para Linux )

El término Linux ABI se refiere a una ABI de espacio de usuario y núcleo. La interfaz binaria de 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 núcleo Linux o de los desarrolladores de la biblioteca C de GNU, y más tarea de las distribuciones Linux y los proveedores de software independientes (ISV) que desean vender y brindar soporte para su software propietario como binarios solo para una única ABI de Linux, en lugar de brindar soporte para 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 el orden de bytes , si ambos son compatibles.

Debe ser posible 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 libre y de código abierto son, por ejemplo, GNU Compiler Collection , LLVM / Clang .

Existen muchas API internas del núcleo que permiten que los subsistemas del núcleo interactúen entre sí. Se mantienen bastante estables, pero no hay garantía de estabilidad. Una API interna del núcleo se puede cambiar cuando una nueva investigación o nuevos conocimientos indiquen esa necesidad; todas las modificaciones y pruebas necesarias deben ser realizadas por el autor.

El núcleo Linux es un núcleo monolítico, por lo que los controladores de dispositivos son componentes del núcleo. Para aliviar la carga de las empresas que mantienen sus controladores de dispositivos (propietarios) fuera del árbol principal del núcleo, se han solicitado repetidamente API estables para los controladores de dispositivos. Los desarrolladores del núcleo Linux han negado repetidamente garantizar API estables en el núcleo para los controladores de dispositivos. Garantizar esto habría hecho flaquear el desarrollo del núcleo Linux en el pasado y lo seguirá haciendo en el futuro y, debido a la naturaleza del software libre y de código abierto, no es necesario. Por lo tanto, por elección propia, el núcleo Linux no tiene una API estable en el núcleo. ^[15]

Dado que no hay API estables dentro del núcleo, no puede haber ABI estables dentro del núcleo. ^[16]

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 se deben implementar sobre las API de nivel inferior. Ejemplos:

• Implementación de las especificaciones OpenGL y Vulkan en controladores gráficos propietarios de Linux y la implementación libre y de código abierto en Mesa .
• Implementación de la especificación OpenAL .
• Capa DirectMedia simple : API de abstracción para entrada/sonido/etc. disponible para muchos sistemas operativos.
• Biblioteca multimedia sencilla y rápida : como la anterior.

• La interfaz de programación de Linux por Michael Kerrisk
• Semáforo (programación)
• Llamada al sistema  : es una función que facilita que los programas soliciten servicios al núcleo.
  • eventofd()
  • netlink  – familia de sockets utilizada para la interconexión de procesos entre el núcleo y los procesos del espacio de usuario, diseñada como sucesora de ioctl ; Netlink fue añadido por Alan Cox durante el desarrollo del núcleo de Linux 1.3 como una interfaz de controlador de caracteres para proporcionar múltiples enlaces de comunicaciones bidireccionales entre el núcleo y el espacio de usuario. Luego, Alexey Kuznetsov lo extendió durante el desarrollo del núcleo de Linux 2.1 para proporcionar una interfaz de mensajería flexible y extensible a la nueva infraestructura de enrutamiento avanzada. Desde entonces, los sockets Netlink se han convertido en una de las principales interfaces que los subsistemas del núcleo proporcionan a las aplicaciones del espacio de usuario en Linux. Los controladores WNIC modernos lo utilizan para comunicarse con el espacio de usuario.
• API de Windows  : artículo sobre las distintas API disponibles en los sistemas operativos Microsoft Windows
  • windows.h  – archivo de encabezado para el lenguaje de programación C que contiene declaraciones para todas las funciones en la API de Windows
• Wine  : una capa de compatibilidad entre Linux y los programas escritos para Microsoft Windows
• libhybris – capa de compatibilidad entre Linux y programas escritos para Android

• La API del kernel de Linux 5.0, API de administración de memoria 5.0 (nuevo formato sphinx )
• La API del kernel de Linux 2.6.20 y 4.12 (en formato htmldocs obsoleto)
• Revisión de los cambios de API/ABI para Linux
• El libro Interfaz de programación de Linux, cambios en la API de Linux y glibc desde que se publicó La interfaz de programación de Linux en 2010
• Mapa interactivo del kernel de Linux con las principales funciones y estructuras de la API, versión PDF
• Controladores de dispositivos Linux por Jonathan Corbet, Greg Kroah-Hartman y Alessandro Rubini, 3.ª edición
• Explicación de la lista enlazada del kernel de Linux Archivado el 25 de septiembre de 2009 en Wayback Machine