Núcleo de Linux

Núcleo de Linux

Tux el pingüino, mascota de Linux [1]
Arranque del kernel de Linux 3.0.0
Autor(es) original(es)	Linus Torvalds
Desarrollador(es)	Colaboradores de la comunidad Linus Torvalds
Lanzamiento inicial	0.02 (5 de octubre de 1991 ; hace 33 años ) ( 5 de octubre de 1991 )
Versión estable	6.11.6 [2]  / 1 de noviembre de 2024
Versión preliminar	6.12-rc6 [3]  / 4 de noviembre de 2024
Repositorio	git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Escrito en	C ( C11 desde 5.18, C89 antes), [4] Rust (desde 6.1), [5] Lenguaje ensamblador
Disponible en	Inglés
Licencia	Solo GPL-2.0 con nota de llamada al sistema de Linux [6] [7] [8] [a]
Sitio web	kernel.org

El núcleo de Linux es un núcleo libre y de código abierto , ^{[12] : 4} similar a UNIX que se utiliza en muchos sistemas informáticos en todo el mundo. El núcleo fue creado por Linus Torvalds en 1991 y pronto fue adoptado como el núcleo del sistema operativo GNU (OS) que fue creado para ser un reemplazo libre para Unix . Desde finales de la década de 1990, se ha incluido en muchas distribuciones de sistemas operativos , muchas de las cuales se llaman Linux . Uno de esos sistemas operativos de núcleo Linux es Android , que se utiliza en muchos dispositivos móviles e integrados.

La mayor parte del código del kernel está escrito en C, tal como lo admite la colección de compiladores GNU (GCC), que tiene extensiones más allá del C estándar. ^{[12] : 18  [13]} El código también contiene código ensamblador para la lógica específica de la arquitectura, como la optimización del uso de la memoria y la ejecución de tareas. ^{[12] : 379–380} El kernel tiene un diseño modular , de modo que los módulos se pueden integrar como componentes de software , incluso cargados dinámicamente. El kernel es monolítico en un sentido arquitectónico, ya que todo el sistema operativo se ejecuta en el espacio del kernel .

Linux se proporciona bajo la Licencia Pública General GNU versión 2 , aunque contiene archivos bajo otras licencias compatibles . ^[11]

En abril de 1991, Linus Torvalds, un estudiante de informática de 21 años de la Universidad de Helsinki , comenzó a trabajar en un sistema operativo, inspirado en UNIX, para un ordenador personal. ^[14] Comenzó con un conmutador de tareas en lenguaje ensamblador Intel 80386 y un controlador de terminal . ^[14] El 25 de agosto de 1991, Torvalds publicó lo siguiente en comp.os.minix , un grupo de noticias de Usenet : ^[15]

Estoy haciendo un sistema operativo (gratuito) (sólo un hobby, no será grande ni profesional como gnu) para clones AT 386(486) . Esto se ha estado gestando desde abril y está empezando a estar listo. Me gustaría recibir comentarios sobre las cosas que a la gente le gustan o no le gustan de minix, ya que mi sistema operativo se le parece un poco (la misma disposición física del sistema de archivos (debido a razones prácticas) entre otras cosas).
Actualmente he portado bash (1.08) y gcc (1.40), y las cosas parecen funcionar. Esto implica que conseguiré algo práctico en unos meses [...]
Sí, está libre de cualquier código minix y tiene un sistema de archivos multiproceso. NO es portátil [ sic ] (usa conmutación de tareas 386, etc.) y probablemente nunca soportará nada más que discos duros AT, ya que eso es todo lo que tengo :-(.

El 17 de septiembre de 1991, Torvalds preparó la versión 0.01 de Linux y la colocó en el servidor FTP "ftp.funet.fi" de la Red Universitaria y de Investigación Finlandesa ( FUNET ). Ni siquiera era ejecutable, ya que su código aún necesitaba Minix para compilarlo y probarlo. ^[16]

El 5 de octubre de 1991, Torvalds anunció la primera versión "oficial" de Linux, la versión 0.02. ^{[17] [16]}

Como mencioné hace un mes, estoy trabajando en una versión gratuita de un programa similar a Minix para computadoras AT-386. Finalmente ha llegado a la etapa en la que es incluso utilizable (aunque puede que no, dependiendo de lo que quieras), y estoy dispuesto a publicar las fuentes para una distribución más amplia. Es solo la versión 0.02... pero he ejecutado bash, gcc, gnu-make, gnu-sed, compress, etc. con éxito.

Linux creció rápidamente a medida que muchos desarrolladores, incluida la comunidad MINIX , contribuyeron al proyecto. ^{[ cita requerida ]} En ese momento, el Proyecto GNU había completado muchos componentes para su reemplazo gratuito de UNIX, el sistema operativo GNU , pero su núcleo, GNU Hurd , estaba incompleto. El proyecto adoptó el núcleo Linux para su sistema operativo. ^[18]

Torvalds etiquetó el núcleo con la versión principal 0 para indicar que aún no estaba destinado al uso general. ^[19] La versión 0.11, lanzada en diciembre de 1991, fue la primera versión alojada en un servidor propio ; compilada en una computadora que ejecutaba el núcleo Linux.

Cuando Torvalds lanzó la versión 0.12 en febrero de 1992, adoptó la Licencia Pública General GNU versión 2 (GPLv2) sobre su licencia anterior, redactada por él mismo, que no permitía la redistribución comercial. ^[20] A diferencia de Unix , todos los archivos fuente de Linux están disponibles gratuitamente, incluidos los controladores de dispositivos . ^[21]

El éxito inicial de Linux fue impulsado por programadores y probadores de todo el mundo. Con el apoyo de las API POSIX , a través de la libC que, cuando es necesaria, actúa como punto de entrada al espacio de direcciones del núcleo, Linux podía ejecutar software y aplicaciones que habían sido desarrollados para Unix. ^[22]

El 19 de enero de 1992 se envió el primer mensaje al nuevo grupo de noticias alt.os.linux . ^[23] El 31 de marzo de 1992, el grupo de noticias pasó a llamarse comp.os.linux . ^[24]

El hecho de que Linux sea un núcleo monolítico en lugar de un micronúcleo fue el tema de un debate entre Andrew S. Tanenbaum , el creador de MINIX, y Torvalds. ^[25] El debate Tanenbaum-Torvalds comenzó en 1992 en el grupo de Usenet comp.os.minix como una discusión general sobre arquitecturas de núcleo. ^{[26] [27]}

La versión 0.95 fue la primera capaz de ejecutar el sistema X Window . ^[28] En marzo de 1994, Linux 1.0.0 fue lanzado con 176.250 líneas de código. ^[29] Como lo indica el número de versión, fue la primera versión considerada adecuada para un entorno de producción . ^[19] En junio de 1996, después del lanzamiento de la versión 1.3, Torvalds decidió que Linux había evolucionado lo suficiente como para justificar un nuevo número mayor, y por eso etiquetó la siguiente versión como versión 2.0.0. ^{[30] [31]} Las características significativas de la versión 2.0 incluían multiprocesamiento simétrico (SMP), soporte para más tipos de procesadores y soporte para seleccionar objetivos de hardware específicos y para habilitar características y optimizaciones específicas de la arquitectura. ^[22] La familia de comandos make *config de kbuild habilita y configura opciones para construir ejecutables de kernel ad hoc ( vmlinux ) y módulos cargables. ^{[32] [33]}

La versión 2.2, publicada el 20 de enero de 1999, ^[34] mejoró la granularidad de bloqueo y la gestión de SMP, agregó soporte para m68k , PowerPC , Sparc64 , Alpha y otras plataformas de 64 bits. ^[35] Además, agregó nuevos sistemas de archivos , incluida la capacidad de solo lectura NTFS de Microsoft . ^[35] En 1999, IBM publicó sus parches al código Linux 2.2.13 para el soporte de la arquitectura S/390 . ^[36]

La versión 2.4.0, publicada el 4 de enero de 2001, ^[37] contenía soporte para ISA Plug and Play , USB y PC Cards . Linux 2.4 agregó soporte para Pentium 4 e Itanium (este último introdujo el ISA ia64 que fue desarrollado conjuntamente por Intel y Hewlett-Packard para reemplazar al antiguo PA-RISC ), y para el nuevo procesador MIPS de 64 bits . ^[38] El desarrollo para 2.4. x cambió un poco en el sentido de que se pusieron a disposición más funciones en toda la serie, incluido el soporte para Bluetooth , Logical Volume Manager (LVM) versión 1, soporte RAID , InterMezzo y sistemas de archivos ext3 .

La versión 2.6.0 se lanzó el 17 de diciembre de 2003. ^[39] El desarrollo de la versión 2.6. x cambió aún más hacia la inclusión de nuevas características en toda la serie. Entre los cambios que se han realizado en la serie 2.6 se encuentran: integración de μClinux en las fuentes del núcleo principal, soporte para PAE , soporte para varias líneas nuevas de CPU , integración de Advanced Linux Sound Architecture (ALSA) en las fuentes del núcleo principal, soporte para hasta 2 ³² usuarios (en lugar de 2 ¹⁶ ), soporte para hasta 2 ²⁹ identificadores de proceso (solo 64 bits, las arquitecturas de 32 bits aún están limitadas a 2 ¹⁵ ), ^[40] aumento sustancial del número de tipos de dispositivos y el número de dispositivos de cada tipo, soporte de 64 bits mejorado, soporte para sistemas de archivos que admiten tamaños de archivo de hasta 16 terabytes , preempción en el núcleo , soporte para la biblioteca de subprocesos POSIX nativos (NPTL), integración de Linux en modo usuario en las fuentes del núcleo principal, integración de SELinux en las fuentes del núcleo principal, soporte para InfiniBand y mucho más.

A partir de las versiones 2.6.x, el núcleo admitió una gran cantidad de sistemas de archivos; algunos diseñados para Linux, como ext3 , ext4 , FUSE , Btrfs , ^[41] y otros nativos de otros sistemas operativos como JFS , XFS , Minix, Xenix , Irix , Solaris , System V , Windows y MS-DOS . ^[42]

Aunque el desarrollo no había utilizado un sistema de control de versiones hasta el momento, en 2002, los desarrolladores de Linux adoptaron BitKeeper , que se puso a su disposición de forma gratuita a pesar de que no era software libre . En 2005, debido a los esfuerzos por aplicarle ingeniería inversa , la empresa propietaria del software revocó su apoyo a la comunidad Linux. En respuesta, Torvalds y otros escribieron Git . El nuevo sistema se escribió en cuestión de semanas y en dos meses se lanzó el primer núcleo oficial creado con él. ^[43]

En 2005 se formó el equipo estable como respuesta a la falta de un árbol de kernel donde la gente pudiera trabajar en correcciones de errores , y que mantendría actualizadas las versiones estables . ^[44] En febrero de 2008 se creó el árbol linux-next para servir como un lugar donde se reunieran los parches que se pretendían fusionar durante el siguiente ciclo de desarrollo. ^{[45] [46]} Varios mantenedores de subsistemas también adoptaron el sufijo -next para árboles que contienen código que pretenden enviar para su inclusión en el próximo ciclo de lanzamiento. A partir de enero de 2014 ^[actualizar], la versión en desarrollo de Linux se mantiene en una rama inestable llamada linux-next . ^[47]

En julio de 2011, Torvalds celebró el 20º aniversario de Linux con el lanzamiento de la versión 3.0.0. ^[30] Como 2.6 había sido el número de versión durante 8 años, se tuvo que agregar al núcleo una nueva personalidad uname26 que informa 3.x como 2.6.40+x para que los programas antiguos pudieran funcionar. ^[48]

La versión 3.0 fue lanzada el 22 de julio de 2011. ^[49] El 30 de mayo de 2011, Torvalds anunció que el gran cambio era "NADA. Absolutamente nada" y pidió: "... asegurémonos de que realmente hacemos que la próxima versión no sea sólo un número nuevo y brillante, sino también un buen núcleo". ^[50] Después de las esperadas 6-7 semanas de proceso de desarrollo, se lanzaría cerca del 20 aniversario de Linux.

El 11 de diciembre de 2012, Torvalds decidió reducir la complejidad del núcleo eliminando el soporte para los procesadores i386 , específicamente al no tener que emular ^[51] la instrucción atómica CMPXCHG introducida con el i486 para permitir mutex confiables , haciendo que la serie de núcleos 3.7 sea la última que aún soporta el procesador original. ^{[52] [53]} La misma serie unificó el soporte para el procesador ARM . ^[54]

El cambio de numeración de 2.6.39 a 3.0, y de 3.19 a 4.0, no implicó ninguna diferenciación técnica significativa; el número de versión principal se incrementó simplemente para evitar grandes números secundarios. ^{[49] [55]} Los núcleos estables 3.xy se lanzaron hasta 3.19 en febrero de 2015. La versión 3.11, lanzada el 2 de septiembre de 2013, ^[56] agregó muchas características nuevas como el nuevo indicador O_TMPFILEopen(2) para reducir las vulnerabilidades de archivos temporales, la administración de energía dinámica experimental AMD Radeon , sondeo de red de baja latencia y zswap (caché de intercambio comprimido). ^[57]

En abril de 2015, Torvalds lanzó la versión 4.0 del kernel. ^[30] Para febrero de 2015, Linux había recibido contribuciones de casi 12.000 programadores de más de 1.200 empresas, incluidos algunos de los proveedores de software y hardware más grandes del mundo. ^[58] La versión 4.1 de Linux, lanzada en junio de 2015, contiene más de 19,5 millones de líneas de código aportadas por casi 14.000 programadores. ^[59]

Linus Torvalds anunció que la versión del kernel 4.22 se numeraría 5.0 en marzo de 2019, afirmando que "'5.0' no significa nada más que los números 4.x comenzaron a ser lo suficientemente grandes como para que me quedara sin dedos de las manos y de los pies". ^[60] Presentó muchas adiciones importantes, como soporte para AMD Radeon FreeSync y la pantalla NVIDIA Xavier, correcciones para F2FS , EXT4 y XFS , soporte restaurado para archivos de intercambio en el sistema de archivos Btrfs y trabajo continuo en los gráficos Intel Icelake Gen11 y en los SoC NXP i.MX8 . ^{[61] [62]} Esta versión fue notablemente más grande que el resto, Torvalds mencionó que "Los cambios generales para toda la versión 5.0 son mucho más grandes". ^[60]

Un total de 1.991 desarrolladores, de los cuales 334 colaboraron por primera vez, agregaron más de 553.000 líneas de código a la versión 5.8, rompiendo el récord que anteriormente tenía la versión 4.9. ^[63]

Según la Encuesta anual para desarrolladores de Stack Overflow de 2019, más del 53% de todos los encuestados han desarrollado software para Linux y alrededor del 27% para Android , ^[64] aunque solo alrededor del 25% desarrolla con sistemas operativos basados ​​en Linux. ^[65]

La mayoría de los sitios web funcionan con sistemas operativos basados ​​en Linux , ^{[66] [67]} y las 500 supercomputadoras más poderosas del mundo utilizan algún tipo de sistema operativo basado en Linux. ^[68]

Las distribuciones de Linux agrupan el núcleo con el software del sistema (por ejemplo, la biblioteca GNU C , systemd y otras utilidades y demonios de Unix ) y una amplia selección de software de aplicación , pero su participación en el uso en los escritorios es baja en comparación con otros sistemas operativos.

Dado que Android , que es Linux, representa la mayoría de los sistemas operativos de dispositivos móviles, ^{[69] [70] [71]} y debido a su creciente uso en dispositivos integrados , Android es significativamente responsable del aumento del uso de Linux en general. ^[22]

Se ha estimado que el coste de rediseñar la versión 2.6.0 del núcleo Linux en un entorno de desarrollo propietario tradicional es de 612 millones de dólares (467 millones de euros, 394 millones de libras esterlinas) a precios de 2004 utilizando el modelo de estimación de persona-mes COCOMO . ^[72] En 2006, un estudio financiado por la Unión Europea estimó el coste de rediseño de la versión 2.6.8 del núcleo en 882 millones de euros (1.140 millones de dólares, 744 millones de libras esterlinas). ^[73]

En octubre de 2008, Amanda McPherson, Brian Proffitt y Ron Hale-Evans volvieron a tratar este tema. Utilizando la metodología de David A. Wheeler, calcularon que el rediseño del núcleo 2.6.25 cuesta ahora 1.300 millones de dólares (parte de un total de 10.800 millones de dólares para rediseñar Fedora 9). ^[74] De nuevo, García-García y Alonso de Magdaleno, de la Universidad de Oviedo (España), calculan que el valor añadido anualmente al núcleo fue de unos 100 millones de euros entre 2005 y 2007 y de 225 millones de euros en 2008; costaría también más de 1.000 millones de euros (unos 1.400 millones de dólares a febrero de 2010) desarrollarlo en la Unión Europea. ^[75]

Al 7 de marzo de 2011 , utilizando las líneas de código ( LOC^[actualizar] ) actuales de un núcleo Linux 2.6.x y las cifras salariales con los cálculos de David A. Wheeler, costaría aproximadamente $3 mil millones (alrededor de €2,2 mil millones) volver a desarrollar el núcleo Linux a medida que sigue creciendo. Un cálculo actualizado al 26 de septiembre de 2018 , utilizando las 20,088,609 LOC (líneas de código) actuales para el núcleo Linux 4.14.14 y el salario promedio nacional actual de programador de EE. UU. de $75,506 muestra que costaría aproximadamente $14,725,449,000 (£11,191,341,000) reescribir el código existente. ^{[76][actualizar]}

La mayoría de los usuarios de Linux lo hacen a través de una distribución de Linux . Algunas distribuciones incluyen el núcleo original o estable. Sin embargo, varios proveedores (como Red Hat y Debian ) mantienen un árbol de fuentes personalizado. Estos suelen actualizarse a un ritmo más lento que la rama original y suelen incluir todas las correcciones de la rama estable correspondiente, pero al mismo tiempo también pueden añadir compatibilidad con controladores o funciones que no se habían publicado en la versión original en la que el proveedor de la distribución comenzó a basar su rama.

Los gráficos no están disponibles debido a problemas técnicos. Hay más información en Phabricator y en MediaWiki.org.

^[77]

La comunidad de desarrolladores del kernel de Linux está formada por unos 5000–6000 miembros. Según el estudio "2017 State of Linux Kernel Development", publicado por la Linux Foundation y que abarca las confirmaciones de las versiones 4.8 a 4.13, unos 1500 desarrolladores contribuyeron de unas 200–250 empresas en promedio. Los 30 principales desarrolladores contribuyeron con un poco más del 16% del código. En cuanto a las empresas, los principales contribuyentes son Intel (13,1%) y Red Hat (7,2%), Linaro (5,6%), IBM (4,1%), el segundo y quinto lugar los ocupan las categorías "ninguno" (8,2%) y "desconocido" (4,1%). ^[78]

En lugar de una hoja de ruta, existen directrices técnicas. En lugar de una asignación central de recursos, existen personas y empresas que tienen un interés en el desarrollo futuro del núcleo Linux, de forma bastante independiente entre sí: personas como Linus Torvalds y yo no planificamos la evolución del núcleo. No nos sentamos a pensar en la hoja de ruta para los próximos dos años y luego asignamos recursos a las distintas características nuevas. Esto se debe a que no tenemos recursos. Los recursos son propiedad de las distintas empresas que utilizan y contribuyen a Linux, así como de los distintos contribuyentes independientes que hay por ahí. Son esas personas las que poseen los recursos y las que deciden...

—Andrew  Morton , 2005

Conflictos notables entre los desarrolladores del kernel de Linux:

• En julio de 2007, Con Kolivas anunció que dejaría de desarrollar para el kernel de Linux. ^{[79] [80]}
• En julio de 2009, Alan Cox renunció a su rol como mantenedor de la capa TTY después de un desacuerdo con Torvalds. ^[81]
• En diciembre de 2010, hubo una discusión entre el mantenedor de SCSI de Linux, James Bottomley, y el mantenedor de SCST, Vladislav Bolkhovitin, sobre qué pila de destino SCSI debería incluirse en el núcleo de Linux. ^[82] Esto molestó a algunos usuarios de Linux. ^[83]
• En junio de 2012, Torvalds dejó muy claro que no estaba de acuerdo con que NVIDIA publicara sus controladores como cerrados. ^[84]
• En abril de 2014, Torvalds prohibió a Kay Sievers enviar parches al kernel de Linux por no solucionar errores que causaban que systemd interactuara negativamente con el kernel. ^[85]
• En octubre de 2014, Lennart Poettering acusó a Torvalds de tolerar el estilo de discusión brusco en las listas de correo relacionadas con el kernel de Linux y de ser un mal modelo a seguir. ^[86]
• En marzo de 2015, Christoph Hellwig presentó una demanda contra VMware por infracción de los derechos de autor sobre el núcleo de Linux. ^[87] Linus Torvalds dejó en claro que no estaba de acuerdo con esta y otras iniciativas similares al calificar a los abogados de enfermedad purulenta. ^[88]
• En abril de 2021, se descubrió que un equipo de la Universidad de Minnesota estaba enviando parches de "mala fe" al núcleo como parte de su investigación. Esto dio lugar a la reversión inmediata de todos los parches enviados por un miembro de la universidad. Además, un responsable de mantenimiento de alto nivel emitió una advertencia de que cualquier parche futuro de la universidad sería rechazado de inmediato. ^{[89] [90]}

Los desarrolladores destacados del kernel de Linux han sido conscientes de la importancia de evitar conflictos entre desarrolladores. ^[91] Durante mucho tiempo no hubo un código de conducta para los desarrolladores del kernel debido a la oposición de Torvalds. ^[92] Sin embargo, el 8 de marzo de 2015 se introdujo un Código de conflicto del kernel de Linux. ^[93] Fue reemplazado el 16 de septiembre de 2018 por un nuevo Código de conducta basado en el Pacto del colaborador . Esto coincidió con una disculpa pública de Torvalds y una breve pausa en el desarrollo del kernel. ^{[94] [95]} El 30 de noviembre de 2018, cumpliendo con el Código de conducta , Jarkko Sakkinen de Intel envió parches que reemplazaban las instancias de "fuck" que aparecían en los comentarios del código fuente con versiones adecuadas centradas en la palabra "hug". ^[96]

Los desarrolladores que se sientan tratados injustamente pueden informar esto al Consejo Asesor Técnico de la Fundación Linux . ^[97] En julio de 2013, el mantenedor del controlador USB 3.0 Sage Sharp le pidió a Torvalds que abordara los comentarios abusivos en la comunidad de desarrollo del kernel. En 2014, Sharp se retiró del desarrollo del kernel de Linux, diciendo que "El enfoque en la excelencia técnica, en combinación con mantenedores sobrecargados y personas con diferentes normas culturales y sociales, significa que los mantenedores del kernel de Linux a menudo son bruscos, groseros o brutales para hacer su trabajo". ^[98] En la conferencia linux.conf.au (LCA) en 2018, los desarrolladores expresaron la opinión de que la cultura de la comunidad ha mejorado mucho en los últimos años. Daniel Vetter, el mantenedor del controlador de kernel de gráficos Intel drm/i915, comentó que el "lenguaje y la discusión bastante violentos" en la comunidad del kernel han disminuido o desaparecido. ^[99]

Laurent Pinchart pidió a los desarrolladores comentarios sobre sus experiencias con la comunidad del kernel en la Embedded Linux Conference Europe de 2017. Los problemas planteados se discutieron unos días después en la Cumbre de Mantenedores. Las preocupaciones sobre la falta de coherencia en la forma en que los mantenedores respondían a los parches enviados por los desarrolladores fueron repetidas por Shuah Khan , el mantenedor del marco de autoprueba del kernel. Torvalds sostuvo que nunca habría coherencia en el manejo de parches porque los diferentes subsistemas del kernel han adoptado, con el tiempo, diferentes procesos de desarrollo. Por lo tanto, se acordó que cada mantenedor del subsistema del kernel documentaría las reglas para la aceptación de parches. ^[100]

¡Linux es evolución, no diseño inteligente !

—  Linus Torvalds, 2005 ^{[101] [102] [103]}

El código fuente del núcleo, también conocido como árbol de fuentes, se administra en el sistema de control de versiones Git , también creado por Torvalds. ^[104]

En 2021 ^[actualizar], la versión 5.11 del kernel de Linux tenía alrededor de 30,34 millones de líneas de código. Aproximadamente el 14 % del código es parte del "núcleo", que incluye código específico de la arquitectura, código del kernel y código mm ^{[ aclaración necesaria ]} , mientras que el 60 % son controladores.

Las contribuciones se envían como parches, en forma de mensajes de texto en la lista de correo del núcleo Linux (LKML) (y a menudo también en otras listas de correo dedicadas a subsistemas particulares). Los parches deben cumplir un conjunto de reglas y un lenguaje formal que, entre otras cosas, describe qué líneas de código deben eliminarse y qué otras deben agregarse a los archivos especificados. Estos parches se pueden procesar automáticamente para que los administradores de sistemas puedan aplicarlos para realizar algunos cambios en el código o para actualizar gradualmente a la siguiente versión. ^[105] Linux también se distribuye en formatos GNU zip (gzip) y bzip2 .

Un desarrollador que desea cambiar el núcleo de Linux escribe y prueba un cambio de código. Dependiendo de lo significativo que sea el cambio y de cuántos subsistemas modifique, el cambio se enviará como un solo parche o en múltiples parches de código fuente . En el caso de un solo subsistema que es mantenido por un solo mantenedor, estos parches se envían como correos electrónicos al mantenedor del subsistema con la lista de correo adecuada en Cc. El mantenedor y los lectores de la lista de correo revisarán los parches y proporcionarán comentarios. Una vez que el proceso de revisión ha terminado, el mantenedor del subsistema acepta los parches en el árbol del núcleo de Git relevante . Si los cambios en el núcleo de Linux son correcciones de errores que se consideran lo suficientemente importantes, se enviará una solicitud de extracción para los parches a Torvalds en unos pocos días. De lo contrario, se enviará una solicitud de extracción a Torvalds durante la siguiente ventana de fusión. La ventana de fusión generalmente dura dos semanas y comienza inmediatamente después del lanzamiento de la versión anterior del núcleo. ^[106] El árbol de código fuente del kernel de Git nombra a todos los desarrolladores que han contribuido al kernel de Linux en el directorio Créditos y todos los mantenedores del subsistema aparecen en Mantenedores . ^[107]

Al igual que con muchos proyectos de software de código abierto de gran tamaño, los desarrolladores deben adherirse al Pacto del Colaborador , un código de conducta destinado a abordar el acoso a los colaboradores pertenecientes a minorías. ^{[108] [109]} Además, para evitar ofensas, se exige el uso de terminología inclusiva dentro del código fuente. ^[110]

Linux está escrito en un lenguaje de programación C especial compatible con GCC , un compilador que extiende el estándar C de muchas maneras, por ejemplo, utilizando secciones en línea de código escritas en lenguaje ensamblador (en la sintaxis "estilo AT&T" de GCC) de la arquitectura de destino.

En septiembre de 2021, el requisito de versión GCC para compilar y construir el kernel de Linux aumentó de GCC 4.9 a 5.1, lo que permite la posibilidad de que el kernel pase de usar código C basado en el estándar C89 a usar código escrito con el estándar C11 , ^[111] y la migración al estándar tendrá lugar en marzo de 2022, con el lanzamiento de Linux 5.18. ^[112]

El soporte inicial para el lenguaje de programación Rust se agregó en Linux 6.1 ^[5] que se lanzó en diciembre de 2022, ^[113] con versiones de kernel posteriores, como Linux 6.2 y Linux 6.3, mejorando aún más el soporte. ^{[114] [115]}

Desde 2002, el código debe cumplir las 21 reglas que componen el estilo de codificación del kernel de Linux. ^{[116] [117]}

Como ocurre con la mayoría del software, el núcleo está versionado como una serie de números separados por puntos.

En las primeras versiones, la versión constaba de tres o cuatro números separados por puntos llamados versión principal , versión secundaria y revisión. ^{[12] : 9} En ese momento, las versiones secundarias con números impares eran para desarrollo y pruebas, mientras que las versiones secundarias con números pares eran para producción. El cuarto dígito opcional indicaba un nivel de parche. ^[19] Las versiones de desarrollo se indicaban con un sufijo de candidato a versión ( -rc ).

Las convenciones de versiones actuales son diferentes. El número par/impar que implica dev/prod ha sido eliminado, y una versión principal se indica con los dos primeros números juntos. Mientras que el marco de tiempo está abierto para el desarrollo de la próxima versión principal, el sufijo -rcN se utiliza para identificar el candidato de lanzamiento n-ésimo para la próxima versión. ^[118] Por ejemplo, el lanzamiento de la versión 4.16 fue precedido por siete 4.16-rcN (de -rc1 a -rc7). Una vez que se lanza una versión estable, su mantenimiento se pasa al equipo estable . Las actualizaciones a una versión estable se identifican con un esquema de tres números (por ejemplo, 4.16.1, 4.16.2, ...). ^[118]

El núcleo se construye generalmente con la cadena de herramientas GNU . El compilador C de GNU, GNU cc, parte de la Colección de compiladores GNU (GCC), es el compilador predeterminado para Linux principal. La secuenciación es manejada por GNU make . El ensamblador GNU (a menudo llamado GAS o GNU as) genera los archivos de objeto a partir del código ensamblador generado por GCC . Finalmente, el enlazador GNU (GNU ld) produce un archivo de núcleo ejecutable enlazado estáticamente llamado vmlinux . Tanto as como ld son parte de las utilidades binarias GNU (binutils).

Durante mucho tiempo, GNU cc fue el único compilador capaz de compilar Linux correctamente. En 2004, Intel afirmó haber modificado el núcleo para que su compilador de C también fuera capaz de compilarlo. ^[119] Hubo otro éxito similar en 2009, con una versión 2.6.22 modificada. ^{[120] [121]} El soporte para el compilador de Intel se ha eliminado en 2023. ^[122]

Desde 2010, se ha estado trabajando para construir Linux con Clang , un compilador alternativo para el lenguaje C; ^[123] al 12 de abril de 2014, el núcleo oficial casi podía ser compilado por Clang. ^{[124] [125]} El proyecto dedicado a este esfuerzo se llama LLVMLinux en honor a la infraestructura del compilador LLVM sobre la que se construyó Clang. ^[126] LLVMLinux no tiene como objetivo bifurcar ni Linux ni LLVM, por lo tanto, es un metaproyecto compuesto de parches que finalmente se envían a los proyectos originales. Al permitir que Linux sea compilado por Clang, los desarrolladores pueden beneficiarse de tiempos de compilación más cortos. ^[127]

En 2017, los desarrolladores completaron la instalación de parches para soportar la creación del kernel de Linux con Clang en la versión 4.15, y trasladaron el soporte para X86-64 y AArch64 a las ramas 4.4, 4.9 y 4.14 del árbol de kernel estable. El Pixel 2 de Google se envió con el primer kernel de Linux creado con Clang , ^[128] aunque existían parches para Pixel (1.ª generación) . ^[129] En 2018, ChromeOS pasó a crear núcleos con Clang de forma predeterminada, ^[130] mientras que Android (sistema operativo) hizo que Clang ^[131] y el enlazador LLD de LLVM ^[132] fueran necesarios para las compilaciones de núcleos en 2019. Google pasó de construir su núcleo de producción utilizado en todos sus centros de datos a construirse con Clang en 2020. ^[133] Hoy, el grupo ClangBuiltLinux coordina las correcciones tanto para Linux como para LLVM para garantizar la compatibilidad, ambos compuestos por miembros de LLVMLinux y con parches ascendentes de LLVMLinux .

Al igual que con cualquier software, los problemas con el núcleo de Linux pueden ser difíciles de solucionar . Los desafíos más comunes están relacionados con el acceso al espacio de usuario y al espacio del núcleo, el uso incorrecto de las primitivas de sincronización y la administración incorrecta del hardware. ^{[12] : 364}

Un error oops es un error no fatal en el núcleo. Después de un error de este tipo, las operaciones continúan con una fiabilidad sospechosa. ^[134]

Un pánico (generado por panic() ) es un error fatal. Después de un error de este tipo, el núcleo imprime un mensaje y detiene la computadora. ^{[12] : 371}

El núcleo permite la depuración mediante la impresión a través de printk () , que almacena los mensajes en un búfer circular (sobrescribiendo las entradas más antiguas con las más nuevas). La llamada al sistema syslog(2) permite leer y borrar el búfer de mensajes y establecer el nivel máximo de registro de los mensajes que se enviarán a la consola. ^[135] Los mensajes del núcleo también se exportan al espacio de usuario a través de la interfaz /dev/kmsg . ^[136]

El mecanismo ftrace permite la depuración mediante rastreo. Se utiliza para supervisar y depurar Linux en tiempo de ejecución y puede analizar latencias en el espacio de usuario debido al mal comportamiento del núcleo. ^{[137] [138] [139] [140]} Además, ftrace permite a los usuarios rastrear Linux en el momento del arranque. ^[141]

kprobes y kretprobes pueden irrumpir en la ejecución del núcleo (como los depuradores en el espacio de usuario) y recopilar información sin interrupciones. ^[142] kprobes se pueden insertar en el código en (casi) cualquier dirección, mientras que kretprobes funcionan en el retorno de la función. uprobes tienen propósitos similares pero también tienen algunas diferencias en el uso y la implementación. ^[143]

Con KGDB, Linux se puede depurar de la misma manera que los programas de espacio de usuario. KGDB requiere una máquina adicional que ejecute GDB y que esté conectada al objetivo que se va a depurar mediante un cable serial o Ethernet . ^[144]

El proyecto del núcleo Linux integra código nuevo de forma continua. El procedimiento operativo estándar es que el software incluido en el proyecto debe funcionar y compilarse sin errores.

A cada subsistema del kernel se le asigna un mantenedor que es responsable de revisar los parches frente a los estándares del código del kernel y de mantener una cola de parches que se pueden enviar a Torvalds dentro de una ventana de fusión que suele ser de varias semanas.

Torvalds fusiona los parches con el código fuente de la versión estable anterior del núcleo Linux, creando así el candidato a versión (-rc) para la próxima versión estable. Una vez que se cierra la ventana de fusión, solo se aceptan correcciones al nuevo código en la versión de desarrollo. La versión de desarrollo -rc del núcleo pasa por pruebas de regresión y, una vez que Torvalds y los encargados del mantenimiento del subsistema la consideran estable, se publica una nueva versión y el proceso de desarrollo comienza de nuevo. ^[145]

El árbol Git que contiene el código fuente del núcleo Linux se conoce como mainline Linux . Cada versión estable del núcleo se origina en el árbol mainline, ^[146] y se publica con frecuencia en kernel.org . Mainline Linux solo tiene soporte sólido para un pequeño subconjunto de los muchos dispositivos que ejecutan Linux. El soporte no principal lo brindan proyectos independientes, como Yocto o Linaro , pero en muchos casos se necesita el núcleo del proveedor del dispositivo. ^[147] El uso de un núcleo de un proveedor probablemente requiera un paquete de soporte de placa .

Mantener un árbol de núcleo fuera del sistema principal de Linux ha demostrado ser difícil. ^[148]

Mainlining se refiere al esfuerzo de agregar soporte para un dispositivo al núcleo principal, ^[149] mientras que anteriormente solo había soporte en una bifurcación o no había soporte en absoluto. Esto generalmente incluye agregar controladores o archivos de árbol de dispositivos . Cuando esto termina, la característica o corrección de seguridad se considera mainlining . ^[150]

El mantenedor de la rama estable, Greg Kroah-Hartman , ha aplicado el término similar a Linux a las bifurcaciones del núcleo descendente realizadas por los proveedores que agregan millones de líneas de código al núcleo principal. ^[151] En 2019, Google declaró que quería utilizar el núcleo Linux principal en Android para reducir la cantidad de bifurcaciones del núcleo. ^[152] El término similar a Linux también se ha aplicado al Subconjunto del núcleo Linux integrable , que no incluye el núcleo Linux principal completo sino un pequeño subconjunto modificado del código. ^[153]

Existen ciertas comunidades que desarrollan núcleos basados ​​en el Linux oficial. Algunos fragmentos de código interesantes de estas bifurcaciones , que incluyen Linux-libre , Compute Node Linux , INK , L4Linux , RTLinux y User-Mode Linux (UML), se han fusionado en la línea principal. ^[154] Algunos sistemas operativos desarrollados para teléfonos móviles inicialmente usaban versiones muy modificadas de Linux, incluidos Google Android , Firefox OS , HP webOS , Nokia Maemo y Jolla Sailfish OS . En 2010, la comunidad Linux criticó a Google por iniciar efectivamente su propio árbol de núcleos: ^{[155] [156]}

Esto significa que cualquier controlador escrito para plataformas de hardware Android no puede fusionarse en el árbol principal del núcleo porque tiene dependencias de código que solo se encuentra en el árbol del núcleo de Google, lo que hace que no pueda compilarse en el árbol kernel.org. Debido a esto, Google ha impedido que una gran parte de los controladores de hardware y el código de la plataforma se fusionen en el árbol principal del núcleo, creando así una rama del núcleo en la que ahora confían varios proveedores diferentes. ^[157]

—  Greg Kroah-Hartman , 2010

En la actualidad, Android utiliza un sistema operativo Linux personalizado ^[158] , en el que se implementan cambios importantes en los controladores de dispositivos, pero se requieren algunos cambios en el código del núcleo. Los desarrolladores de Android también envían parches al sistema operativo Linux oficial que finalmente puede iniciar el sistema operativo Android. Por ejemplo, un Nexus 7 puede iniciar y ejecutar el sistema operativo Linux principal. ^[158]

En una presentación en 2001 en el Museo de Historia de la Computación , Torvalds dijo lo siguiente en respuesta a una pregunta sobre las distribuciones de Linux que utilizan o no exactamente las mismas fuentes de kernel:

No lo son... bueno, lo son y no lo son. No hay un único núcleo. Cada distribución tiene sus propios cambios. Eso ha estado sucediendo desde prácticamente el primer día. No sé si recordarás que Yggdrasil era conocido por tener cambios bastante extremos en el núcleo e incluso hoy en día todos los principales proveedores tienen sus propios ajustes porque tienen una parte del mercado en la que están interesados ​​y, francamente, así es como debería ser. Porque si todo el mundo espera que una persona, yo, pueda rastrear todo, ese no es el objetivo de la GPL. Ese no es el objetivo de tener un sistema abierto. Así que, en realidad, el hecho de que una distribución decida que algo es tan importante para ellos que agregarán parches incluso cuando no está en el núcleo estándar, eso es una muy buena señal para mí. Así es, por ejemplo, cómo se agregó algo como ReiserFS. Y la razón por la que ReiserFS es el primer sistema de archivos con registro que se integró en el núcleo estándar no fue porque ame a Hans Reiser. Fue porque SUSE empezó a distribuir ReiserFS como su núcleo estándar, lo que me dijo "ok". Esto está en uso en producción. La gente normal lo está haciendo. Deben saber algo que yo no sé. Así que, en un sentido muy real, lo que hacen muchas casas de distribución es que son parte de este "hagamos nuestra propia rama" y "hagamos nuestros cambios en esto". Y debido a la GPL, puedo tomar las mejores partes de ellos. ^[159]

—  Linus Torvalds , 2001

La última versión y las versiones anteriores se mantienen por separado. La mayoría de las últimas versiones del núcleo fueron supervisadas por Torvalds. ^[160]

La comunidad de desarrolladores del kernel de Linux mantiene un kernel estable aplicando correcciones a errores de software que se han descubierto durante el desarrollo del kernel estable posterior. Por lo tanto, www.kernel.org siempre enumera dos kernels estables. El siguiente kernel estable de Linux se publica entre 8 y 12 semanas después.

Algunas versiones están diseñadas para brindar soporte a largo plazo , como versiones con corrección de errores durante dos o más años. ^[161]

Aunque parezca contradictorio, el núcleo de Linux es monolítico y modular. El núcleo se clasifica como un núcleo monolítico arquitectónicamente, ya que todo el sistema operativo se ejecuta en el espacio del núcleo. El diseño es modular, ya que se puede ensamblar a partir de módulos que, en algunos casos, se cargan y descargan en tiempo de ejecución. ^{[12] : 338  [162]} Admite características que antes solo estaban disponibles en núcleos de código cerrado de sistemas operativos no libres.

El resto del artículo utiliza la convención de sistemas operativos UNIX y similares a Unix de las páginas del manual . El número que sigue al nombre de un comando, interfaz u otra característica especifica la sección (es decir, el tipo de componente o característica del sistema operativo) a la que pertenece. Por ejemplo, execve(2) se refiere a una llamada del sistema y exec(3) se refiere a un contenedor de biblioteca de espacio de usuario.

A continuación se presenta una descripción general del diseño arquitectónico y de las características notables.

• Computación concurrente e incluso (con la disponibilidad de suficientes núcleos de CPU para tareas que estén listas para ejecutarse) ejecución paralela real de muchos procesos a la vez (cada uno de ellos con uno o más hilos de ejecución ) en arquitecturas SMP y NUMA .
• Selección y configuración de cientos de características y controladores del núcleo (utilizando uno de los comandos de la familia make *config antes de la compilación), ^{[163] [33] [32]} modificación de los parámetros del núcleo antes del arranque (normalmente insertando instrucciones en las líneas del menú de GRUB2 ) y ajuste fino del comportamiento del núcleo en tiempo de ejecución (utilizando la interfaz sysctl(8) para /proc/sys/ ). ^{[164] [165] [166]}
• Configuración (de nuevo usando los comandos make *config ) y modificaciones en tiempo de ejecución de las políticas ^[167] (a través de nice(2) , setpriority(2) y la familia de llamadas al sistema sched_*(2) ) de los programadores de tareas que permiten la multitarea preventiva (tanto en modo de usuario como, desde la serie 2.6, en modo kernel ^{[168] [169]} ); el programador de primera programación virtual con fecha límite elegible más temprana (EEVDF), ^[170] es el programador predeterminado de Linux desde 2023 y usa un árbol rojo-negro que puede buscar, insertar y eliminar información de proceso ( estructura de tarea ) con complejidad de tiempo O(log n) , donde n es el número de tareas ejecutables. ^{[171] [172]}
• Gestión avanzada de memoria con memoria virtual paginada .
• Mecanismo de comunicación y sincronización entre procesos .
• Un sistema de archivos virtual sobre varios sistemas de archivos concretos ( ext4 , Btrfs , XFS , JFS , FAT32 y muchos más).
• Programadores de E/S configurables, llamada al sistema ioctl(2) ^[173] que manipula los parámetros de dispositivo subyacentes de archivos especiales (es una llamada de sistema no estándar, ya que los argumentos, retornos y semántica dependen del controlador de dispositivo en cuestión), soporte para E/S asincrónica POSIX ^[174] (sin embargo, debido a que escalan pobremente con aplicaciones multiproceso, se tuvo que crear una familia de llamadas de sistema de E/S específicas de Linux ( io_*(2) ^[175] ) para la gestión de contextos de E/S asincrónicas adecuados para el procesamiento concurrente).
• Virtualización a nivel de SO (con Linux-VServer ), paravirtualización y virtualización asistida por hardware (con KVM o Xen , y usando QEMU para emulación de hardware); ^{[176] [177] [178] [179] [180] [181] En el} hipervisor Xen , el núcleo Linux proporciona soporte para construir distribuciones Linux (como openSUSE Leap y muchas otras) que funcionan como Dom0 , que son servidores host de máquinas virtuales que proporcionan el entorno de gestión para las máquinas virtuales del usuario ( DomU ). ^[182]
• Virtualización de E/S con VFIO y SR-IOV . La E/S de función virtual (VFIO) expone el acceso directo del dispositivo al espacio del usuario en un entorno protegido de memoria segura (IOMMU). Con VFIO, un invitado de VM puede acceder directamente a los dispositivos de hardware en el servidor host de VM. Esta técnica mejora el rendimiento, si se compara con la virtualización completa y la paravirtualización. Sin embargo, con VFIO, los dispositivos no se pueden compartir con varios invitados de VM. La virtualización de E/S de raíz única (SR-IOV) combina las ganancias de rendimiento de VFIO y la capacidad de compartir un dispositivo con varios invitados de VM (pero requiere hardware especial que debe ser capaz de aparecer ante dos o más invitados de VM como dispositivos diferentes). ^[183]
• Mecanismos de seguridad para el control de acceso discrecional y obligatorio (SELinux, AppArmor, POSIX ACLs y otros). ^{[184] [185]}
• Varios tipos de protocolos de comunicación en capas (incluido el conjunto de protocolos de Internet ).
• Multiprocesamiento asimétrico a través del subsistema RPMsg .

La mayoría de los controladores de dispositivos y extensiones del núcleo se ejecutan en el espacio del núcleo ( anillo 0 en muchas arquitecturas de CPU ), con acceso completo al hardware. Algunas excepciones se ejecutan en el espacio del usuario ; ejemplos notables son los sistemas de archivos basados ​​en FUSE /CUSE y partes de UIO. ^{[186] [187]} Además, el sistema X Window y Wayland , el sistema de ventanas y protocolos de servidor de visualización que la mayoría de las personas usan con Linux, no se ejecutan dentro del núcleo. De manera diferente, la interfaz real con las GPU de las tarjetas gráficas es un subsistema dentro del núcleo llamado Direct Rendering Manager (DRM).

A diferencia de los núcleos monolíticos estándar, los controladores de dispositivos se configuran fácilmente como módulos y se cargan o descargan mientras el sistema está en funcionamiento y también se pueden interrumpir en determinadas condiciones para manejar correctamente las interrupciones de hardware y soportar mejor el multiprocesamiento simétrico . ^{[169] Por elección propia, Linux no tiene} una interfaz binaria de aplicación de controlador de dispositivo estable . ^[188]

Linux generalmente utiliza protección de memoria y memoria virtual y también puede manejar acceso a memoria no uniforme , ^[189] sin embargo, el proyecto ha absorbido μClinux , que también hace posible ejecutar Linux en microcontroladores sin memoria virtual. ^[190]

El hardware se representa en la jerarquía de archivos. Las aplicaciones de usuario interactúan con los controladores de dispositivos a través de entradas en los directorios /dev o /sys ^{. [191]} La información del proceso se asigna al directorio /proc . ^[191]

Linux comenzó como un clon de UNIX y apunta a cumplir con POSIX y Single UNIX Specification . ^[193] El núcleo proporciona llamadas al sistema y otras interfaces que son específicas de Linux. Para ser incluido en el núcleo oficial, el código debe cumplir con un conjunto de reglas de licencia. ^{[6] [11]}

La interfaz binaria de la aplicación Linux (ABI) entre el núcleo y el espacio de usuario tiene cuatro grados de estabilidad (estable, en prueba, obsoleto, eliminado); ^[194] Se espera que las llamadas del sistema nunca cambien para preservar la compatibilidad de los programas del espacio de usuario que dependen de ellas. ^[195]

Los módulos de kernel cargables (LKM), por diseño, no pueden depender de una ABI estable. ^[188] Por lo tanto, siempre deben volver a compilarse cada vez que se instala un nuevo ejecutable de kernel en un sistema, de lo contrario no se cargarán. Los controladores en árbol que están configurados para convertirse en una parte integral del ejecutable de kernel ( vmlinux ) están vinculados estáticamente por el proceso de compilación.

No existe garantía de estabilidad de la API interna del núcleo a nivel de fuente ^[188] y, debido a esto, el código del controlador de dispositivo , así como el código de cualquier otro subsistema del núcleo, debe mantenerse actualizado con la evolución del núcleo. Cualquier desarrollador que realice un cambio en la API debe corregir cualquier código que falle como resultado de su cambio. ^[196]

El conjunto de la API del núcleo Linux que se refiere a las interfaces expuestas a las aplicaciones de usuario se compone fundamentalmente de llamadas al sistema específicas de UNIX y Linux . ^[197] Una llamada al sistema es un punto de entrada al núcleo Linux. ^[198] Por ejemplo, entre las específicas de Linux se encuentra la familia de llamadas al sistema clone(2) . ^[199] La mayoría de las extensiones deben habilitarse definiendo la macro en un archivo de encabezado o cuando se compila el código del espacio de usuario. ^[200]_GNU_SOURCE

Las llamadas al sistema solo se pueden invocar a través de instrucciones de ensamblaje que permiten la transición desde el espacio de usuario sin privilegios al espacio de kernel privilegiado en el anillo 0. Por esta razón, la biblioteca estándar de C (libC) actúa como un contenedor para la mayoría de las llamadas al sistema Linux, al exponer funciones de C que, si es necesario, ^[201] ingresan de manera transparente al kernel que se ejecutará en nombre del proceso que realiza la llamada. ^[197] Para las llamadas al sistema que no están expuestas por libC, como el mutex rápido del espacio de usuario , ^[202] la biblioteca proporciona una función llamada syscall(2) que se puede usar para invocarlas explícitamente. ^[203]

Los pseudo sistemas de archivos (por ejemplo, los sistemas de archivos sysfs y procfs ) y los archivos especiales (por ejemplo, /dev/random, /dev/sda, /dev/ttyy muchos otros) constituyen otra capa de interfaz para las estructuras de datos del núcleo que representan dispositivos de hardware o lógicos (software). ^{[204] [205]}

Debido a las diferencias existentes entre los cientos de implementaciones del sistema operativo Linux, los objetos ejecutables, aunque estén compilados, ensamblados y vinculados para ejecutarse en una arquitectura de hardware específica (es decir, utilizan la ISA del hardware de destino), a menudo no pueden ejecutarse en diferentes distribuciones de Linux. Este problema se debe principalmente a las configuraciones específicas de la distribución y a un conjunto de parches aplicados al código del núcleo de Linux, diferencias en las bibliotecas del sistema, los servicios (daemons), las jerarquías del sistema de archivos y las variables de entorno.

El estándar principal en materia de compatibilidad binaria y de aplicaciones de las distribuciones Linux es el Linux Standard Base (LSB). ^{[206] [207]} Sin embargo, el LSB va más allá de lo que concierne al núcleo Linux, ya que también define las especificaciones del escritorio, las bibliotecas X y Qt que poco tienen que ver con él. ^[208] La versión 5 del LSB se basa en varios estándares y borradores (POSIX, SUS, X/Open, File System Hierarchy (FHS) y otros). ^[209]

Las partes del LSB más relevantes para el núcleo son la ABI general (gABI), ^[210] especialmente la ABI del sistema V ^{[211] [212]} y el formato ejecutable y de enlace (ELF), ^{[213] [214]} y la ABI específica del procesador (psABI), por ejemplo la especificación central para X86-64. ^{[215] [216]}

La ABI estándar para la forma en que los programas de usuario x86_64 invocan llamadas del sistema es cargar el número de llamada al sistema en el registro rax , y los otros parámetros en rdi , rsi , rdx , r10 , r8 y r9 , y finalmente poner la instrucción de ensamblaje de llamada al sistema en el código. ^{[217] [218] [219]}

Existen varias API internas del núcleo entre los subsistemas del núcleo. Algunas están disponibles sólo dentro de los subsistemas del núcleo, mientras que un conjunto algo limitado de símbolos internos del núcleo (es decir, variables, estructuras de datos y funciones) está expuesto a módulos cargables dinámicamente (por ejemplo, controladores de dispositivos cargados a pedido) ya sea que se exporten con las macros EXPORT_SYMBOL() y EXPORT_SYMBOL_GPL() ^{[221] [222]} (la última reservada para módulos publicados bajo una licencia compatible con GPL). ^[223]

Linux proporciona API en el núcleo que manipulan estructuras de datos (por ejemplo, listas enlazadas , árboles de base , ^[224] árboles rojo-negros , ^[225] colas ) o realizan rutinas comunes (por ejemplo, copiar datos desde y hacia el espacio del usuario, asignar memoria, imprimir líneas en el registro del sistema, etc.) que se han mantenido estables al menos desde la versión 2.6 de Linux. ^{[226] [227] [228]}

Las API dentro del núcleo incluyen bibliotecas de servicios comunes de bajo nivel utilizados por los controladores de dispositivos:

• Interfaces SCSI y libATA  : respectivamente, un protocolo de comunicación basado en paquetes punto a punto para dispositivos de almacenamiento conectados a dispositivos USB, SATA, SAS, Fibre Channel, FireWire, ATAPI, ^[229] y una biblioteca en el núcleo para soportar controladores y dispositivos host [S]ATA. ^[230]
• Direct Rendering Manager (DRM) y Kernel Mode Setting (KMS): para interactuar con GPU y satisfacer las necesidades del hardware de video acelerado en 3D moderno, ^[231] y para configurar la resolución de pantalla, la profundidad de color y la frecuencia de actualización ^[232]
• Búferes DMA ( DMA-BUF ): para compartir búferes para el acceso directo a la memoria de hardware entre múltiples controladores de dispositivos y subsistemas ^{[233] [234] [235]}
• Video4Linux  – para hardware de captura de vídeo
• Arquitectura avanzada de sonido Linux (ALSA): para tarjetas de sonido
• Nueva API  : para controladores de interfaz de red
• mac80211 y cfg80211 – para controladores de interfaz de red inalámbrica ^{[236] [237]}

Los desarrolladores de Linux decidieron no mantener una ABI estable dentro del núcleo. Los módulos compilados para una versión específica del núcleo no se pueden cargar en otra versión sin volver a compilarlos. ^[188]

Esta sección puede resultar confusa o poco clara para los lectores . En particular, no describe el modelo general y se centra en detalles técnicos minuciosos de la interfaz que probablemente no proporcionen un contexto claro. Ayúdenos a aclarar la sección . Es posible que haya una discusión sobre esto en la página de discusión . ( Julio de 2023 ) ( Aprenda cómo y cuándo eliminar este mensaje )

Linux crea procesos mediante las llamadas al sistema clone(2) o la más reciente clone3(2) ^[238] . Estas llamadas al sistema crean nuevas entidades que van desde nuevos procesos independientes (cada uno con un identificador especial llamado TGID dentro de la estructura de datos task_struct en el espacio del núcleo, aunque ese mismo identificador se llama PID en el espacio del usuario), hasta nuevos subprocesos dentro del proceso que realiza la llamada. ^{[239] [240]}

Si el ejecutable está vinculado dinámicamente a bibliotecas compartidas, se utiliza un vinculador dinámico para encontrar y cargar los objetos necesarios, preparar el programa para su ejecución y luego ejecutarlo. ^[241]

La biblioteca de subprocesos POSIX nativos (NPTL) ^[242] proporciona la interfaz de subprocesos estándar POSIX ( pthreads ) al espacio de usuario.

El núcleo proporciona los mecanismos futex(7) (mutex rápido en el espacio de usuario) para el bloqueo y sincronización en el espacio de usuario. ^[243] La mayoría de las operaciones se realizan en el espacio de usuario, pero puede ser necesario comunicarse con el núcleo mediante la llamada al sistema futex(2) . ^[202]

A diferencia de los hilos del espacio de usuario descritos anteriormente, los hilos del núcleo se ejecutan en el espacio del núcleo. ^[244]

El programador de procesos de Linux es modular, en el sentido de que permite diferentes clases y políticas de programación. ^{[245] [246]} Las clases del programador son algoritmos de programación conectables que se pueden registrar con el código base del programador. Cada clase programa diferentes tipos de procesos. El código central del programador itera sobre cada clase en orden de prioridad y elige el programador de mayor prioridad que tenga una entidad programable de tipo struct sched_entity lista para ejecutarse. ^{[12] : 46–47} Las entidades pueden ser subprocesos, grupos de subprocesos e incluso todos los procesos de un usuario específico.

Linux proporciona tanto preempción de usuario como preempción de kernel completo . ^{[12] : 62–63} La preempción reduce la latencia , aumenta la capacidad de respuesta, ^[247] y hace que Linux sea más adecuado para aplicaciones de escritorio y en tiempo real .

Para las tareas normales, por defecto, el núcleo utiliza la clase Completely Fair Scheduler (CFS), introducida en la versión 2.6.23. ^[171] El planificador se define como una macro en un encabezado de C como SCHED_NORMAL. En otros núcleos POSIX, una política similar conocida como SCHED_OTHERasigna porciones de tiempo de CPU (es decir, asigna porciones absolutas del tiempo de procesador dependiendo de la prioridad predeterminada o calculada dinámicamente de cada proceso). El CFS de Linux elimina las porciones de tiempo absolutas y asigna una proporción justa de tiempo de CPU, como una función de parámetros como el número total de procesos ejecutables y el tiempo que ya se han ejecutado; esta función también tiene en cuenta un tipo de peso que depende de sus prioridades relativas (valores nice). ^{[12] : 46–50}

Con la preempción del usuario, el planificador del núcleo puede reemplazar el proceso actual con la ejecución de un cambio de contexto a uno diferente que, por lo tanto, adquiere los recursos informáticos para ejecutarse (CPU, memoria y más). Lo hace de acuerdo con el algoritmo CFS (en particular, utiliza una variable llamada vruntime para ordenar las entidades y luego elige la que tiene el vruntime más pequeño, es decir, la entidad programable que ha tenido la menor participación del tiempo de CPU), a la política activa del planificador y a las prioridades relativas. ^[248] Con la preempción del núcleo, el núcleo puede preemptarse a sí mismo cuando un manejador de interrupciones regresa, cuando las tareas del núcleo se bloquean y siempre que un subsistema llama explícitamente a la función schedule().

El núcleo también contiene dos clases de programación en tiempo real compatibles con POSIX ^[249]SCHED_FIFO llamadas (realtime first-in-first-out ) y SCHED_RR(realtime round-robin ), ambas tienen prioridad sobre la clase predeterminada. ^[245] Una política de programación adicional conocida como SCHED DEADLINE, que implementa el algoritmo de fecha límite más temprana primero (EDF), se agregó en la versión 3.14 del núcleo, lanzada el 30 de marzo de 2014. ^{[250] [251]} SCHED_DEADLINE tiene prioridad sobre todas las demás clases de programación.

Los parches en tiempo real PREEMPT_RT, incluidos en la línea principal de Linux desde la versión 2.6, proporcionan un programador determinista , la eliminación de la preempción y la desactivación de interrupciones (cuando sea posible), PI Mutexes (es decir, primitivas de bloqueo que evitan la inversión de prioridad), ^{[252] [253]} soporte para temporizadores de eventos de alta precisión (HPET), lectura-copia-actualización preemptiva (RCU), subprocesos IRQ (forzados) y otras características menores. ^{[254] [255] [256]}

En 2023, Peter Zijlstra propuso reemplazar CFS con un programador de fecha límite virtual elegible más temprano (EEVDF), ^{[257] [258]} para evitar la necesidad de parches de "latencia agradable" de CFS. ^[259] El programador EEVDF reemplazó a CFS en la versión 6.6 del kernel de Linux. ^[260]

El núcleo tiene diferentes causas de concurrencia (por ejemplo, interrupciones, mitades inferiores, prelación de tareas del núcleo y de los usuarios, multiprocesamiento simétrico). ^{[12] : 167}

Para proteger regiones críticas (secciones de código que deben ejecutarse atómicamente), ubicaciones de memoria compartida (como variables globales y otras estructuras de datos con alcance global) y regiones de memoria que son modificables asincrónicamente por hardware (por ejemplo, que tienen el calificador de tipo C ), Linux proporciona un gran conjunto de herramientas. Consisten en tipos atómicos (que solo pueden manipularse mediante un conjunto de operadores específicos), spinlocks , semáforos , mutexes , ^{[261] [12] : 176–198  [262]} y algoritmos sin bloqueo (por ejemplo, RCUs ). ^{[263] [264] [265]} La mayoría de los algoritmos sin bloqueo se construyen sobre barreras de memoria con el propósito de hacer cumplir el orden de la memoria y evitar efectos secundarios no deseados debido a la optimización del compilador . ^{[266] [267] [268] [269]}volatile

PREEMPT_RTEl código incluido en la línea principal de Linux proporciona RT-mutexes , un tipo especial de Mutex que no deshabilita la preempción y tiene soporte para herencia de prioridad. ^{[270] [271]} Casi todos los bloqueos se cambian a bloqueos inactivos cuando se usa la configuración para operación en tiempo real. ^{[272] [256] [271]} La herencia de prioridad evita la inversión de prioridad al otorgar a una tarea de baja prioridad que mantiene un bloqueo en disputa la prioridad de un bloqueo en espera de mayor prioridad hasta que se libere ese bloqueo. ^{[273] [274]}

Linux incluye un validador de bloqueo del núcleo llamado Lockdep . ^{[275] [276]}

Aunque la gestión de interrupciones podría verse como un único trabajo, se divide en dos. Esta división en dos se debe a las diferentes restricciones de tiempo y a las necesidades de sincronización de las tareas que componen la gestión. La primera parte está formada por una rutina de servicio de interrupciones asíncrona que en Linux se conoce como mitad superior , mientras que la segunda parte la lleva a cabo uno de los tres tipos de las llamadas mitades inferiores ( softirq , tasklets y colas de trabajo ). ^{[12] : 133–137}

Las rutinas de servicio de interrupción de Linux se pueden anidar. Una nueva IRQ puede entrar en una ISR de alta prioridad que prevalezca sobre cualquier otra ISR de menor prioridad.

Linux implementa memoria virtual con tablas de páginas de 5 niveles . ^[277] El kernel no es paginable (lo que significa que siempre reside en la memoria física y no se puede intercambiar con el disco) y no hay protección de memoria (no hay señales SIGSEGV , a diferencia del espacio de usuario), por lo tanto, las violaciones de memoria conducen a inestabilidad y fallas del sistema. ^{[12] : 20} La memoria de usuario es paginable de forma predeterminada, aunque la paginación para áreas de memoria específicas se puede deshabilitar con la familia mlock() de llamadas del sistema .

La información del marco de página se mantiene en estructuras de datos apropiadas (del tipo struct page ) que se rellenan inmediatamente después del arranque y se conservan hasta el apagado, independientemente de si están asociadas con páginas virtuales. El espacio de direcciones físicas se divide en diferentes zonas, según las limitaciones arquitectónicas y el uso previsto. También se admiten sistemas NUMA con múltiples bancos de memoria. ^[278]

Se pueden asignar dinámicamente pequeños fragmentos de memoria en el espacio del núcleo a través de la familia de kmalloc()API y liberarlos con la variante adecuada de kfree(). vmalloc()y kvfree()se utilizan para fragmentos grandes prácticamente contiguos. alloc_pages()asigna la cantidad deseada de páginas enteras.

El kernel solía incluir los asignadores SLAB, SLUB y SLOB como alternativas configurables. ^{[280] [281]} El asignador SLOB se eliminó en Linux 6.4 ^[282] y el asignador SLAB se eliminó en Linux 6.8. ^[283] El único asignador restante es SLUB, que apunta a la simplicidad y la eficiencia, ^[281] es PREEMPT_RTcompatible ^[284] y se introdujo en Linux 2.6.

Aunque no fue diseñado originalmente para ser portable , ^{[15] [285]} Linux es ahora uno de los núcleos de sistemas operativos más ampliamente portados, y se ejecuta en una amplia gama de sistemas, desde la arquitectura ARM hasta los mainframes IBM z/Architecture . El primer puerto se realizó en la plataforma Motorola 68000. Las modificaciones al núcleo fueron tan fundamentales que Torvalds consideró la versión de Motorola como una bifurcación y un "sistema operativo similar a Linux". ^[285] Sin embargo, eso llevó a Torvalds a liderar una importante reestructuración del código para facilitar la portabilidad a más arquitecturas informáticas. El primer Linux que, en un solo árbol de fuentes, tenía código para más de i386 solo, era compatible con la plataforma DEC Alpha AXP de 64 bits. ^{[286] [287] [285]}

Linux se ejecuta como el sistema operativo principal en Summit de IBM ; a partir de octubre de 2019 , las 500 supercomputadoras más rápidas del mundo ejecutan algún sistema operativo basado en el núcleo Linux, ^[288] un gran cambio desde 1998, cuando la primera supercomputadora Linux se agregó a la lista. ^{[289][actualizar]}

Linux también ha sido portado a varios dispositivos portátiles como el iPhone 3G y el iPod de Apple . ^[290]

En 2007, se inició el proyecto LKDDb para crear una base de datos completa de hardware y protocolos conocidos por los núcleos de Linux. ^[291] La base de datos se crea automáticamente mediante el análisis estático de las fuentes del núcleo. Más tarde, en 2014, se lanzó el proyecto Linux Hardware para recopilar automáticamente una base de datos de todas las configuraciones de hardware probadas con la ayuda de los usuarios de varias distribuciones de Linux. ^[292]

This section needs to be updated. Please help update this article to reflect recent events or newly available information. Last update: April 2015 (September 2023)

Las actualizaciones sin reinicio pueden incluso aplicarse al núcleo mediante el uso de tecnologías de parcheo en vivo como Ksplice , kpatch y kGraft . Las bases minimalistas para el parcheo en vivo del núcleo se fusionaron en la línea principal del núcleo Linux en la versión 4.0 del núcleo, que se lanzó el 12 de abril de 2015. Esas bases, conocidas como livepatch y basadas principalmente en la funcionalidad ftrace del núcleo, forman un núcleo común capaz de soportar parcheo en caliente tanto por kGraft como por kpatch, al proporcionar una interfaz de programación de aplicaciones (API) para los módulos del núcleo que contienen parches en caliente y una interfaz binaria de aplicación (ABI) para las utilidades de administración del espacio de usuario. Sin embargo, el núcleo común incluido en el núcleo Linux 4.0 solo admite la arquitectura x86 y no proporciona ningún mecanismo para garantizar la coherencia a nivel de función mientras se aplican los parches en caliente. A partir de abril de 2015 ^[update], hay un trabajo en curso para portar kpatch y kGraft al núcleo común de parcheo en vivo proporcionado por la línea principal del núcleo Linux. ^{[293] [294] [295]}

Los errores del núcleo presentan problemas potenciales de seguridad. Por ejemplo, pueden permitir la escalada de privilegios o crear vectores de ataque de denegación de servicio . A lo largo de los años, se han encontrado y solucionado numerosos errores que afectaban a la seguridad del sistema. ^[296] Con frecuencia se implementan nuevas características para mejorar la seguridad del núcleo. ^{[297] [298]}

Las capacidades (7) ya se han presentado en la sección sobre procesos e hilos. Android hace uso de ellas y systemd ofrece a los administradores un control detallado sobre las capacidades de los procesos. ^[299]

Linux ofrece una gran cantidad de mecanismos para reducir la superficie de ataque del núcleo y mejorar la seguridad, que se conocen colectivamente como los Módulos de seguridad de Linux (LSM). ^[300] Comprenden el módulo Security-Enhanced Linux (SELinux), cuyo código fue desarrollado originalmente y luego publicado al público por la NSA , ^[301] y AppArmor ^[185] entre otros. SELinux ahora se desarrolla y mantiene activamente en GitHub . ^[184] SELinux y AppArmor brindan soporte para políticas de seguridad de control de acceso, incluido el control de acceso obligatorio (MAC), aunque difieren profundamente en complejidad y alcance.

Otra característica de seguridad es Seccomp BPF (SECure COMPuting con filtros de paquetes Berkeley) que funciona filtrando parámetros y reduciendo el conjunto de llamadas del sistema disponibles para las aplicaciones del usuario. ^[302]

Los críticos han acusado a los desarrolladores del kernel de encubrir fallas de seguridad, o al menos de no anunciarlas; en 2008, Torvalds respondió a esto con lo siguiente: ^{[303] [304]}

Personalmente, considero que los errores de seguridad son simplemente "errores normales". No los oculto, pero tampoco tengo ningún motivo para pensar que sea una buena idea rastrearlos y anunciarlos como algo especial... una de las razones por las que me niego a molestarme con todo el circo de la seguridad es que creo que glorifica (y, por lo tanto, fomenta) el comportamiento incorrecto. Convierte en "héroes" a la gente de seguridad, como si la gente que no se limita a solucionar los errores normales no fuera tan importante. De hecho, todos los aburridos errores normales son mucho más importantes, simplemente porque hay muchos más. No creo que se deba glorificar o preocuparse por algún agujero de seguridad espectacular como si fuera más "especial" que un espectacular fallo aleatorio debido a un mal bloqueo.

Las distribuciones de Linux suelen publicar actualizaciones de seguridad para corregir vulnerabilidades en el núcleo de Linux. Muchas ofrecen versiones de soporte a largo plazo que reciben actualizaciones de seguridad para una determinada versión del núcleo de Linux durante un período prolongado.

Inicialmente, Torvalds publicó Linux bajo una licencia que prohibía cualquier uso comercial. ^[305] Esto cambió en la versión 0.12 con un cambio a la Licencia Pública General GNU versión 2 (GPLv2). ^[20] Esta licencia permite la distribución y venta de versiones de Linux, tanto modificadas como no modificadas, pero requiere que todas esas copias se publiquen bajo la misma licencia y estén acompañadas por el código fuente completo correspondiente (o que, si se solicita, se dé acceso gratuito al mismo). ^[306] Torvalds ha descrito el licenciamiento de Linux bajo la GPLv2 como "lo mejor que he hecho en mi vida". ^[305]

El núcleo Linux está licenciado explícitamente bajo la Licencia Pública General GNU versión 2 únicamente (GPL-2.0-only) con una excepción explícita de llamada al sistema (Linux-syscall-note), ^{[6] [9] [10]} sin ofrecer al licenciatario la opción de elegir cualquier versión posterior, que es una extensión común de la GPL. El código contribuido debe estar disponible bajo una licencia compatible con la GPL . ^{[11] [196]}

Hubo un debate considerable sobre cuán fácilmente se podría cambiar la licencia para usar versiones posteriores de la GPL (incluida la versión 3), y si este cambio es incluso deseable. ^[307] El propio Torvalds indicó específicamente en el lanzamiento de la versión 2.4.0 que su propio código se publica solo bajo la versión 2. ^[308] Sin embargo, los términos de la GPL establecen que si no se especifica ninguna versión, se puede usar cualquier versión, ^[309] y Alan Cox señaló que muy pocos otros contribuyentes de Linux habían especificado una versión particular de la GPL. ^[310]

En septiembre de 2006, una encuesta a 29 programadores clave del kernel indicó que 28 preferían la GPLv2 al borrador vigente de la GPLv3. Torvalds comentó: "Creo que varios forasteros... creían que yo personalmente era el extraño porque públicamente no he sido un gran fan de la GPLv3". ^[311] Este grupo de desarrolladores de kernel de alto perfil, incluidos Torvalds, Greg Kroah-Hartman y Andrew Morton , comentaron en los medios de comunicación sus objeciones a la GPLv3. ^[312] Hicieron referencia a cláusulas relacionadas con DRM / tivoización , patentes, "restricciones adicionales" y advirtieron sobre una balcanización del "Universo de Código Abierto" por la GPLv3. ^{[312] [313]} Torvalds, que decidió no adoptar la GPLv3 para el kernel de Linux, reiteró sus críticas incluso años después. ^[314]

Se debate si algunos módulos de kernel cargables (LKM) deben considerarse trabajos derivados según la ley de derechos de autor y, por lo tanto, si caen o no bajo los términos de la GPL.

De acuerdo con las reglas de la licencia, los LKM que utilizan solo un subconjunto público de las interfaces del núcleo ^{[221] [222]} son ​​trabajos no derivados, por lo que Linux brinda a los administradores del sistema los mecanismos para cargar objetos binarios fuera del árbol en el espacio de direcciones del núcleo. ^[11]

Hay algunos módulos cargables fuera del árbol que hacen un uso legítimo de la característica del kernel dma_buf . ^[315] El código compatible con GPL ciertamente puede usarlo. Sin embargo, un posible caso de uso diferente sería Nvidia Optimus que combina una GPU rápida con una GPU integrada de Intel, donde la GPU de Nvidia escribe en el búfer de cuadros de Intel cuando está activo. Pero, Nvidia no puede usar esta infraestructura porque necesita eludir una regla que solo puede ser utilizada por LKM que también son GPL. ^[223] Alan Cox respondió en LKML , rechazando una solicitud de uno de los ingenieros de Nvidia para eliminar esta aplicación técnica de la API. ^[316] Torvalds afirmó claramente en LKML que "[Afirmo] que los módulos de kernel solo binarios SON derivados "por defecto"". ^[317]

Por otra parte, Torvalds también ha dicho que "[una] zona gris en particular es algo así como un controlador que fue escrito originalmente para otro sistema operativo (es decir, claramente no un trabajo derivado de Linux en su origen). ESA es un área gris, y _esa_ es el área donde personalmente creo que algunos módulos pueden ser considerados como no trabajos derivados simplemente porque no fueron diseñados para Linux y no dependen de ningún comportamiento especial de Linux". ^{[318] Los controladores de gráficos} propietarios , en particular, son ampliamente discutidos.

Siempre que se cargan módulos propietarios en Linux, el núcleo se marca a sí mismo como "contaminado" ^[319] y, por lo tanto, los informes de errores de núcleos contaminados a menudo serán ignorados por los desarrolladores.

El kernel oficial, que es la rama git de Linus en el repositorio kernel.org, contiene blobs binarios publicados bajo los términos de la licencia GNU GPLv2. ^{[6] [11]} Linux también puede buscar sistemas de archivos para localizar blobs binarios, firmware propietario, controladores u otros módulos ejecutables, y luego puede cargarlos y vincularlos al espacio del kernel. ^[320]

Cuando es necesario (por ejemplo, para acceder a dispositivos de arranque o por velocidad), el firmware se puede integrar al kernel, lo que significa integrar el firmware en vmlinux ; sin embargo, esta no siempre es una opción viable por cuestiones técnicas o legales (por ejemplo, no está permitido hacer esto con firmware que no sea compatible con GPL, aunque esto es bastante común de todos modos). ^[321]

Linux es una marca registrada de Linus Torvalds en los Estados Unidos, la Unión Europea y algunos otros países. ^{[322] [323]} Una batalla legal por la marca registrada comenzó en 1996, cuando William Della Croce, un abogado que nunca estuvo involucrado en el desarrollo de Linux, comenzó a solicitar tarifas de licencia para el uso de la palabra Linux . Después de que se demostró que la palabra era de uso común mucho antes del primer uso reclamado por Della Croce, la marca registrada fue otorgada a Torvalds. ^{[324] [325] [326]}

En octubre de 2024, Greg Kroah-Hartman eliminó los nombres de los rusos del MAINTAINERSarchivo, pero mantuvo el código de dichos subsistemas. Esta eliminación fue apoyada por Torvalds. ^[327]

• Microkernel  : núcleo que proporciona menos servicios que un núcleo tradicional
• Historial de versiones del kernel de Linux  – Historial de versiones del kernel de Linux
• Comparación de sistemas operativos
• Comparación de núcleos de sistemas operativos
• Linux  – Familia de sistemas operativos tipo Unix
• Minix 3  – Sistema operativo tipo Unix
• macOS  – Sistema operativo para ordenadores Apple
• Microsoft Windows  – Sistemas operativos de computadoras