núcleo de Linux

La comunidad de desarrolladores del kernel de Linux comprende entre 5000 y 6000 miembros. Según el informe "Estado del desarrollo del kernel de Linux de 2017", un estudio publicado por la Linux Foundation que abarca las contribuciones de las versiones 4.8 a 4.13, aproximadamente 1500 desarrolladores contribuyeron desde unas 200 a 250 empresas en promedio. Los 30 desarrolladores principales contribuyeron con algo más del 16 % del código. En cuanto a las empresas, los principales contribuyentes son Intel (13,1 %), Red Hat (7,2 %), Linaro (5,6 %) e IBM (4,1 %). El segundo y quinto lugar corresponden a las categorías "ninguno" (8,2 %) y "desconocido" (4,1 %). ^{[ 83 ]}

En lugar de una hoja de ruta, existen directrices técnicas. En lugar de una asignación centralizada de recursos, hay personas y empresas que tienen un interés común en el desarrollo del kernel de Linux, de forma totalmente independiente: personas como Linus Torvalds y yo no planificamos la evolución del kernel. No nos sentamos a elaborar la hoja de ruta para los próximos dos años ni a asignar recursos a las distintas funcionalidades nuevas. Esto se debe a que no disponemos de recursos. Los recursos pertenecen a las diversas corporaciones que utilizan y contribuyen a Linux, así como a los diversos colaboradores independientes. Son quienes poseen los recursos quienes deciden...

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. ^{[ 84 ] [ 85 ]}
• En julio de 2009, Alan Cox renunció a su cargo como mantenedor de la capa TTY tras un desacuerdo con Torvalds. ^{[ 86 ]}
• En diciembre de 2010, hubo una discusión entre James Bottomley, mantenedor de SCSI de Linux, y Vladislav Bolkhovitin, mantenedor de SCST, sobre qué pila de destino SCSI debería incluirse en el kernel de Linux. ^{[ 87 ]} Esto molestó a algunos usuarios de Linux. ^{[ 88 ]}
• En junio de 2012, Torvalds dejó muy claro que no estaba de acuerdo con que NVIDIA publicara sus controladores como cerrados. ^{[ 89 ]}
• En abril de 2014, Torvalds prohibió a Kay Sievers enviar parches al kernel de Linux por no solucionar errores que causaban una interacción negativa entre systemd y el kernel. ^{[ 90 ]}
• 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 ejemplo a seguir. ^{[ 91 ]}
• En marzo de 2015, Christoph Hellwig presentó una demanda contra VMware por infracción de los derechos de autor del núcleo de Linux. ^{[ 92 ]} Linus Torvalds dejó claro que no estaba de acuerdo con esta ni con iniciativas similares, calificando a los abogados de enfermedad purulenta. ^{[ 93 ]}
• 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 resultó en la reversión inmediata de todos los parches enviados por miembros de la universidad. Además, un responsable de mantenimiento principal advirtió que cualquier parche futuro de la universidad sería rechazado de inmediato. ^{[ 94 ] [ 95 ]}
• En febrero de 2025, Hector Martin renunció como mantenedor del proyecto Asahi Linux (que agregó soporte para sistemas Apple Silicon a Linux) y subsistemas del kernel relacionados debido a desacuerdos sobre el uso del lenguaje de programación Rust en el kernel. ^{[ 96 ]}
• En junio de 2025, el sistema de archivos Bcachefs estaba generando tensión con Torvalds ^{[ 97 ]} y en septiembre de 2025 fue eliminado del kernel de Linux a partir de la versión 6.18. ^{[ 98 ]}

Los desarrolladores prominentes del kernel de Linux han sido conscientes de la importancia de evitar conflictos entre desarrolladores. ^{[ 99 ]} Durante mucho tiempo no hubo un código de conducta para los desarrolladores del kernel debido a la oposición de Torvalds. ^{[ 100 ]} Se introdujo un Código de Conflicto del Kernel de Linux el 8 de marzo de 2015. ^{[ 101 ]} 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. ^{[ 102 ] [ 103 ]} El 30 de noviembre de 2018, cumpliendo con el Código de Conducta , Jarkko Sakkinen de Intel envió parches reemplazando las instancias de "fuck" que aparecían en los comentarios del código fuente con versiones adecuadas centradas en la palabra "hug". ^{[ 104 ]}

Los desarrolladores que se sientan tratados injustamente pueden informar de esto al Consejo Asesor Técnico de la Fundación Linux . ^{[ 105 ]} En julio de 2013, el mantenedor del controlador USB 3.0, Sage Sharp, 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 los mantenedores sobrecargados y las personas con diferentes normas culturales y sociales, significa que los mantenedores del kernel de Linux a menudo son directos, groseros o brutales para hacer su trabajo". ^{[ 106 ]} En la conferencia linux.conf.au (LCA) de 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 del kernel de gráficos Intel drm/i915, comentó que el "lenguaje y las discusiones bastante violentas" en la comunidad del kernel han disminuido o desaparecido. ^{[ 107 ]}

Laurent Pinchart solicitó 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 Maintainers Summit. Shuah Khan , responsable del marco de autodiagnóstico del kernel, se hizo eco de las preocupaciones sobre la falta de coherencia en la forma en que los responsables del kernel respondían a los parches enviados por los desarrolladores. Torvalds sostuvo que nunca habría coherencia en el manejo de los parches porque los diferentes subsistemas del kernel han adoptado, con el tiempo, diferentes procesos de desarrollo. Por lo tanto, se acordó que cada responsable del kernel documentaría las reglas para la aceptación de parches. ^{[ 108 ]}

El código fuente del kernel, también conocido como árbol de código fuente, se gestiona en el sistema de control de versiones Git , también creado por Torvalds. ^{[ 112 ]}

A partir de 2021La 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 forma parte del "núcleo", que incluye código específico de la arquitectura, código del kernel y código de gestión de memoria, 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 kernel de Linux (LKML) (y a menudo también en otras listas de correo dedicadas a subsistemas particulares). Los parches deben ajustarse a un conjunto de reglas y a un lenguaje formal que, entre otras cosas, describe qué líneas de código se deben eliminar y cuáles se deben agregar a los archivos especificados. Estos parches se pueden procesar automáticamente para que los administradores del sistema puedan aplicarlos para realizar solo algunos cambios en el código o para actualizar incrementalmente a la siguiente versión. ^{[ 113 ]} Linux también se distribuye en formatos GNU zip (gzip) y bzip2 .

Un desarrollador que desea modificar el kernel de Linux escribe y prueba un cambio de código. Dependiendo de la importancia del cambio y de la cantidad de subsistemas que modifique, este se enviará como un único parche o en varios parches de código fuente . En el caso de un único subsistema mantenido por un solo responsable, estos parches se envían por correo electrónico al responsable del subsistema con copia a la lista de correo correspondiente. El responsable y los lectores de la lista de correo revisarán los parches y proporcionarán comentarios. Una vez finalizado el proceso de revisión, el responsable del subsistema acepta los parches en el árbol del kernel de Git correspondiente . Si los cambios en el kernel de Linux son correcciones de errores consideradas lo suficientemente importantes, se enviará una solicitud de extracción (pull request) de los parches a Torvalds en pocos días. De lo contrario, se enviará una solicitud de extracción a Torvalds durante la siguiente ventana de fusión. Esta ventana suele durar dos semanas y comienza inmediatamente después del lanzamiento de la versión anterior del kernel. ^{[ 114 ]} 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 Credits y todos los mantenedores de subsistemas se enumeran en Maintainers . ^{[ 115 ]}

Como ocurre con muchos proyectos de software de código abierto de gran envergadura, 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. ^{[ 116 ] [ 117 ]} Además, para evitar ofensas , se exige el uso de terminología inclusiva en el código fuente. ^{[ 118 ]}

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 de código en línea escritas en el lenguaje ensamblador (con la sintaxis "AT&T" de GCC) de la arquitectura de destino.

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

El soporte inicial para el lenguaje de programación Rust se agregó en Linux 6.1, ^{[ 121 ]} que se lanzó en diciembre de 2022, ^{[ 122 ]} y versiones posteriores del kernel, como Linux 6.2 y Linux 6.3, mejoraron aún más el soporte. ^{[ 123 ] [ 124 ]}

Desde 2002, el código debe cumplir con las 21 reglas del estilo de codificación del kernel de Linux. ^{[ 125 ] [ 126 ]}

Como ocurre con la mayoría del software, el núcleo se versiona mediante una serie de números separados por puntos.

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

Las convenciones de versionado actuales son diferentes. Se ha eliminado el número impar/par que implicaba desarrollo/producción, y una versión principal se indica con los dos primeros números juntos. Si bien el plazo para el desarrollo de la siguiente versión principal está abierto, el sufijo -rcN se utiliza para identificar la enésima versión candidata para la siguiente versión. ^{[ 127 ]} 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 pasa al equipo estable . Las actualizaciones de una versión estable se identifican mediante un esquema de tres números (por ejemplo, 4.16.1, 4.16.2, ...). ^{[ 127 ]}

El núcleo se suele compilar con el conjunto de herramientas GNU . El compilador GNU C, GNU cc, que forma parte de la Colección de Compiladores GNU (GCC), es el compilador predeterminado para la versión principal de Linux. La secuenciación la gestiona GNU make . El ensamblador GNU (a menudo llamado GAS o GNU as) genera los archivos objeto a partir del código ensamblador generado por GCC . Finalmente, el enlazador GNU (GNU ld) produce un archivo ejecutable del núcleo enlazado estáticamente llamado vmlinux . Tanto as como ld forman 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 kernel para que su compilador C también pudiera compilarlo. ^{[ 128 ]} En 2009 se informó de otro éxito similar con una versión modificada 2.6.22. ^{[ 129 ] [ 130 ]} El soporte para el compilador de Intel se eliminó en 2023. ^{[ 131 ]}

Desde 2010, se ha estado trabajando en la compilación de Linux con Clang , un compilador alternativo para el lenguaje C; ^{[ 132 ]} al 12 de abril de 2014, el kernel oficial casi podía compilarse con Clang. ^{[ 133 ] [ 134 ]} El proyecto dedicado a este esfuerzo se llama LLVMLinux, en honor a la infraestructura del compilador LLVM sobre la que se basa Clang. ^{[ 135 ]} LLVMLinux no pretende bifurcar ni Linux ni LLVM, por lo que es un metaproyecto compuesto por parches que finalmente se envían a los proyectos upstream. Al permitir que Linux se compile con Clang, los desarrolladores pueden beneficiarse de tiempos de compilación más cortos. ^{[ 136 ]}

En 2017, los desarrolladores completaron la incorporación de parches para admitir la compilación del kernel de Linux con Clang en la versión 4.15, habiendo adaptado el soporte para X86-64 y AArch64 a las ramas 4.4, 4.9 y 4.14 del árbol del kernel estable. El Pixel 2 de Google se lanzó con el primer kernel de Linux compilado con Clang , ^{[ 137 ]} aunque existían parches para Pixel (primera generación) . ^{[ 138 ]} En 2018, ChromeOS pasó a compilar kernels con Clang por defecto, ^{[ 139 ]} mientras que Android hizo que Clang ^{[ 140 ]} y el enlazador LLD de LLVM ^{[ 141 ]} fueran necesarios para las compilaciones del kernel en 2019. Google cambió su kernel de producción utilizado en todos sus centros de datos para que se compilara con Clang en 2020. ^{[ 142 ]} El grupo ClangBuiltLinux coordina correcciones tanto para Linux como para LLVM para garantizar la compatibilidad, ambos compuestos por miembros de LLVMLinux y habiendo incorporado parches de LLVMLinux .

Como ocurre con cualquier software, los problemas con el kernel de Linux pueden ser difíciles de solucionar . Los desafíos comunes se relacionan con el acceso al espacio de usuario frente al espacio del kernel, el uso incorrecto de las primitivas de sincronización y la gestión incorrecta del hardware. ^{[ 16 ] : 364}

Un error de tipo "oops" es un error no fatal en el núcleo. Tras dicho error, las operaciones continúan con una fiabilidad cuestionable. ^{[ 143 ]}

Un pánico (generado por panic() ) es un error fatal. Tras dicho error, el núcleo imprime un mensaje y detiene el ordenador. ^{[ 16 ] : 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 recientes). 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. ^{[ 144 ]} Los mensajes del núcleo también se exportan al espacio de usuario a través de la interfaz /dev/kmsg . ^{[ 145 ]}

El mecanismo ftrace permite la depuración mediante el rastreo. Se utiliza para monitorizar y depurar Linux en tiempo de ejecución y puede analizar las latencias del espacio de usuario debidas a un comportamiento anómalo del kernel. ^{[ 146 ] [ 147 ] [ 148 ] [ 149 ]} Además, ftrace permite a los usuarios rastrear Linux en el momento del arranque. ^{[ 150 ]}

Las kprobes y kretprobes pueden interrumpir la ejecución del kernel (como los depuradores en el espacio de usuario) y recopilar información sin interrumpir la ejecución. ^{[ 151 ]} Las kprobes se pueden insertar en el código en (casi) cualquier dirección, mientras que las kretprobes funcionan al retornar una función. Las uprobes tienen propósitos similares, pero también presentan algunas diferencias en su uso e implementación. ^{[ 152 ]}

Con KGDB, Linux se puede depurar de forma muy similar a 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 serie o Ethernet . ^{[ 153 ]}

El proyecto del kernel de Linux integra código nuevo de forma continua. El procedimiento operativo estándar establece que el software incorporado al proyecto debe funcionar y compilarse sin errores.

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

Torvalds integra los parches en el código fuente de la versión estable anterior del kernel de Linux, creando así la versión candidata (-rc) para la siguiente versión estable. Una vez cerrada la ventana de integración, solo se aceptan correcciones para el nuevo código de la versión de desarrollo. La versión de desarrollo -rc del kernel se somete a pruebas de regresión y, una vez que Torvalds y los mantenedores del subsistema la consideran estable, se publica una nueva versión y el proceso de desarrollo comienza de nuevo. ^{[ 154 ]}

El árbol Git que contiene el código fuente del kernel de Linux se denomina mainline Linux . Cada lanzamiento estable del kernel se origina en el árbol mainline, ^{[ 155 ]} y se publica frecuentemente en kernel.org . Mainline Linux solo tiene soporte sólido para un pequeño subconjunto de los muchos dispositivos que ejecutan Linux. El soporte fuera del mainline lo proporcionan proyectos independientes, como Yocto o Linaro , pero en muchos casos se necesita el kernel del fabricante del dispositivo. ^{[ 156 ]} El uso de un kernel del fabricante probablemente requiere un paquete de soporte de placa .

Mantener un árbol de kernel fuera de la rama principal de Linux ha demostrado ser difícil. ^{[ 157 ]}

El término "mainlining" se refiere al esfuerzo de agregar soporte para un dispositivo al núcleo principal, ^{[ 158 ]} cuando anteriormente solo existía soporte en una bifurcación o no existía soporte alguno. Esto generalmente incluye agregar controladores o archivos de árbol de dispositivos . Cuando esto se completa, la característica o la corrección de seguridad se considera integrada al núcleo principal . ^{[ 159 ]}

El responsable de la rama estable, Greg Kroah-Hartman , ha aplicado el término «similar a Linux» a las bifurcaciones del kernel derivadas de proveedores que añaden millones de líneas de código al kernel principal. ^{[ 160 ]} En 2019, Google declaró que quería utilizar el kernel principal de Linux en Android para reducir el número de bifurcaciones del kernel. ^{[ 161 ]} El término «similar a Linux» también se ha aplicado al Embeddable Linux Kernel Subset , que no incluye el kernel principal completo de Linux, sino un pequeño subconjunto modificado del código. ^{[ 162 ]}

Hay 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 con la rama principal. ^{[ 163 ]} Algunos sistemas operativos desarrollados para teléfonos móviles inicialmente utilizaron versiones muy modificadas de Linux, incluyendo Google Android , Firefox OS , HP webOS , Nokia Maemo y Jolla Sailfish OS . En 2010, la comunidad Linux criticó a Google por iniciar de hecho su propio árbol de núcleo: ^{[ 164 ] [ 165 ]}

Esto significa que los controladores escritos para plataformas de hardware Android no pueden integrarse en el árbol principal del kernel porque dependen de código que solo se encuentra en el árbol del kernel de Google, lo que provoca que no se compilen 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 integren en el árbol principal del kernel. De hecho, se ha creado una rama del kernel de la que dependen varios proveedores. ^{[ 166 ]}

Actualmente, Android utiliza una versión personalizada de Linux ^{[ 167 ]} donde 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 a la versión oficial de Linux que finalmente permite el arranque del sistema operativo Android. Por ejemplo, un Nexus 7 puede arrancar y ejecutar la versión principal de Linux. ^{[ 167 ]}

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

No son... bueno, sí lo son y no lo son. No hay un único kernel. Cada distribución tiene sus propios cambios. Eso ha estado sucediendo prácticamente desde el primer día. No sé si recuerdas que Yggdrasil era conocido por tener cambios bastante extremos en el kernel e incluso hoy todos los principales proveedores tienen sus propios ajustes porque tienen una parte del mercado que les interesa y, francamente, así es como debe ser. Porque si todos esperan que una persona, yo, pueda rastrear todo, ese no es el propósito de la GPL. Ese no es el propósito de tener un sistema abierto. Así que, de hecho, el hecho de que una distribución decida que algo es tan importante para ellos que agregará parches incluso cuando no está en el kernel estándar, eso es una muy buena señal para mí. Así es, por ejemplo, como 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 kernel estándar no fue porque adore a Hans Reiser . Fue porque SUSE empezó a distribuir ReiserFS como su kernel estándar, lo que me hizo pensar: "Vale". Esto se usa en producción. La gente normal lo hace. Deben saber algo que yo no sé. Así que, en cierto modo, lo que hacen muchas distribuciones es formar parte de esto de "creemos nuestra propia rama" y "hagamos nuestros cambios". Y gracias a la GPL, puedo tomar las mejores partes de ellas. ^{[ 168 ]}

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

La comunidad de desarrolladores del kernel de Linux mantiene un kernel estable aplicando correcciones a los errores de software descubiertos durante el desarrollo de la siguiente versión estable. Por lo tanto, www.kernel.org siempre muestra dos versiones estables del kernel. La siguiente versión estable del kernel de Linux se publica aproximadamente entre 8 y 12 semanas después.

Algunas versiones están designadas para soporte a largo plazo como versiones de corrección de errores durante dos o más años. ^{[ 170 ]}

Algunos proyectos han intentado reducir el tamaño del kernel de Linux. Uno de ellos es TinyLinux . En 2014, Josh Triplett inició el árbol de código fuente -tiny para una versión de tamaño reducido. ^{[ 171 ] [ 172 ] [ 173 ] [ 174 ]}

Linux comenzó como un clon de UNIX y busca cumplir con POSIX y la Especificación Única de UNIX . ^{[ 206 ]} El núcleo proporciona llamadas al sistema y otras interfaces específicas de Linux. Para ser incluido en el núcleo oficial, el código debe cumplir con un conjunto de reglas de licencia. ^{[ 10 ] [ 15 ]}

La interfaz binaria de aplicaciones (ABI) de Linux entre el núcleo y el espacio de usuario tiene cuatro grados de estabilidad (estable, en pruebas, obsoleto, eliminado); ^{[ 207 ]} Se espera que las llamadas al sistema nunca cambien para preservar la compatibilidad con los programas de espacio de usuario que dependen de ellas. ^{[ 208 ]}

Los módulos de kernel cargables (LKM), por diseño, no pueden depender de una ABI estable. ^{[ 201 ]} Por lo tanto, deben recompilarse siempre que se instale un nuevo ejecutable del kernel en un sistema; de lo contrario, no se cargarán. Los controladores integrados que están configurados para convertirse en parte integral del ejecutable del kernel ( vmlinux ) se enlazan estáticamente durante el proceso de compilación.

No existe garantía de estabilidad de la API del kernel a nivel de código fuente ^{[ 201 ]} y, por ello, el código del controlador del dispositivo , así como el de cualquier otro subsistema del kernel, debe mantenerse actualizado con la evolución del kernel. Todo desarrollador que realice un cambio en la API está obligado a corregir cualquier código que falle como resultado de dicho cambio. ^{[ 209 ]}

API en el kernel

Existen varias API internas del kernel entre los subsistemas del kernel. Algunas están disponibles solo dentro de los subsistemas del kernel, mientras que un conjunto algo limitado de símbolos del kernel (es decir, variables, estructuras de datos y funciones) se expone a módulos de carga dinámica (por ejemplo, controladores de dispositivos cargados bajo demanda) ya sea que se exporten con las macros EXPORT_SYMBOL() y EXPORT_SYMBOL_GPL() ^{[ 234 ] [ 235 ]} (esta última reservada para módulos publicados bajo una licencia compatible con GPL). ^{[ 236 ]}

Linux proporciona API en el núcleo que manipulan estructuras de datos (por ejemplo, listas enlazadas , árboles radix , ^{[ 237 ]} árboles rojo-negro , ^{[ 238 ]} colas ) o realizan rutinas comunes (por ejemplo, copiar datos desde y hacia el espacio de 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. ^{[ 239 ] [ 240 ] [ 241 ]}

Las API integradas en el 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 y ATAPI, ^{[ 242 ]} y una biblioteca en el núcleo para admitir controladores y dispositivos host [S]ATA. ^{[ 243 ]} 
• Direct Rendering Manager (DRM) y Kernel Mode Setting (KMS) : para interactuar con las GPU y admitir las necesidades del hardware de vídeo acelerado en 3D moderno, ^{[ 244 ]} y para configurar la resolución de pantalla, la profundidad de color y la frecuencia de actualización ^{[ 245 ].} 
• Búferes DMA ( DMA-BUF ) – para compartir búferes para acceso directo a memoria de hardware a través de múltiples controladores de dispositivos y subsistemas ^{[ 246 ] [ 247 ] [ 248 ]} 
• Video4Linux – para hardware de captura de vídeo 
• Arquitectura de sonido avanzada de 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 ^{[ 249 ] [ 250 ]} 

Linux, al igual que otros núcleos , tiene la capacidad de gestionar procesos, incluyendo su creación, suspensión, reanudación y terminación. A diferencia de otros sistemas operativos, el núcleo de Linux implementa los procesos como un grupo de hilos llamados tareas. Si dos tareas comparten el mismo TGID , se denominan grupo de tareas en la terminología del núcleo. Cada tarea está representada por una estructura de datos task_struct . Cuando se crea un proceso, se le asigna un identificador único global llamado PID , que no puede ser compartido ^{[ 251 ] [ 252 ].}

Se puede crear un nuevo proceso llamando a la familia de llamadas al sistema clone ^{[ 253 ]} o a la llamada al sistema fork . El kernel puede suspender y reanudar los procesos enviando señales como SIGSTOP y SIGCONT . Un proceso puede terminar por sí mismo llamando a la llamada al sistema exit , o puede ser terminado por otro proceso enviando señales como SIGKILL , SIGABRT o SIGINT .

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

La biblioteca de subprocesos POSIX nativa (NPTL) ^{[ 255 ]} proporciona la interfaz de subprocesos estándar POSIX ( pthreads ) al espacio de usuario. El kernel no tiene conocimiento de procesos ni subprocesos, pero sí de tareas ; por lo tanto, los subprocesos se implementan en el espacio de usuario. En Linux, los subprocesos se implementan como tareas que comparten recursos, mientras que si no los comparten, se consideran procesos independientes.

El núcleo proporciona los mecanismos futex(7) (mutex rápido en el espacio de usuario) para el bloqueo y la sincronización en el espacio de usuario. ^{[ 256 ]} 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) . ^{[ 215 ]}

A diferencia de los subprocesos del espacio de usuario descritos anteriormente, los subprocesos del kernel se ejecutan en el espacio del kernel. ^{[ 257 ]} Son subprocesos creados por el propio kernel para tareas especializadas; tienen privilegios como el kernel y no están vinculados a ningún proceso o aplicación.

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

Linux proporciona tanto la preempción del usuario como (seleccionable, hasta) ^{[ 260 ] [ 261 ]} preempción completa del kernel . ^{[ 16 ] : 62–63} La preempción reduce la latencia , aumenta la capacidad de respuesta, ^{[ 262 ]} y hace que Linux sea más adecuado para aplicaciones de escritorio y en tiempo real . Esto tiene un costo en el rendimiento, ya que el trabajo que se interrumpe empeora el comportamiento de la caché. ^{[ 261 ]}

Para tareas normales, por defecto, el kernel utiliza la clase Completely Fair Scheduler (CFS)., introducido en la versión 2.6.23. ^{[ 184 ]} El planificador se define como una macro en un encabezado C como SCHED_NORMAL. En otros núcleos POSIX, una política similar conocida como SCHED_OTHERasigna segmentos de tiempo de CPU (es decir, asigna segmentos absolutos del tiempo del procesador dependiendo de la prioridad predeterminada o calculada dinámicamente de cada proceso). El CFS de Linux elimina los segmentos de tiempo absolutos y asigna una proporción justa del tiempo de CPU, en 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 una especie de ponderación que depende de sus prioridades relativas (valores nice). ^{[ 16 ] : 46–50}

Con la preempción del usuario, el planificador del kernel puede reemplazar el proceso actual con la ejecución de un cambio de contexto a uno diferente que, por lo tanto, adquiere los recursos de computación para su ejecución (CPU, memoria, etc.). Lo hace de acuerdo con el algoritmo CFS (en particular, usa una variable llamada vruntime para ordenar entidades y luego elige la que tiene el vruntime más pequeño, - es decir, la entidad planificable que ha tenido la menor porción de tiempo de CPU), a la política del planificador activo y a las prioridades relativas. ^{[ 263 ]} Con la preempción del kernel, el kernel puede preemptionarse a sí mismo cuando un manejador de interrupciones regresa, cuando las tareas del kernel se bloquean y siempre que un subsistema llama explícitamente a la función schedule().

El kernel también contiene dos clases de planificación en tiempo real compatibles con POSIX ^{[ 264 ]}SCHED_FIFO llamadas ( primero en entrar, primero en salir en tiempo real ) y SCHED_RR( ronda rotativa en tiempo real ), ambas tienen precedencia sobre la clase predeterminada. ^{[ 258 ]} Se agregó una política de planificación adicional conocida como SCHED_DEADLINE, que implementa el algoritmo de plazo más temprano primero (EDF), en la versión 3.14 del kernel, publicada el 30 de marzo de 2014. ^{[ 265 ] [ 266 ]}SCHED_DEADLINE tiene precedencia sobre todas las demás clases de planificación.

Los parches en tiempo real PREEMPT_RT, incluidos en la rama principal de Linux desde la versión 2.6, proporcionan un planificador determinista , la eliminación de la desalojo de interrupciones y la interrupción (cuando sea posible), mutexes PI (es decir, primitivas de bloqueo que evitan la inversión de prioridad), ^{[ 267 ] [ 268 ]} soporte para temporizadores de eventos de alta precisión (HPET), actualización de lectura-copia preemptiva (RCU), subprocesos IRQ (forzados) y otras características menores. ^{[ 269 ] [ 270 ] [ 271 ]}

En 2023, Peter Zijlstra propuso reemplazar CFS con un planificador de plazo virtual más temprano elegible primero (EEVDF), ^{[ 272 ] [ 273 ]} para evitar la necesidad de parches "latency nice" de CFS. ^{[ 274 ]} El planificador EEVDF reemplazó a CFS en la versión 6.6 del kernel de Linux. ^{[ 183 ]}

El núcleo tiene diferentes causas de concurrencia (por ejemplo, interrupciones, mitades inferiores, expropiación de tareas del núcleo y de los usuarios, multiprocesamiento simétrico). ^{[ 16 ] : 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 pueden ser modificadas asincrónicamente por hardware (por ejemplo, con el calificador de tipo C volatile ), Linux proporciona un amplio conjunto de herramientas. Estas consisten en tipos atómicos (que solo pueden ser manipulados por un conjunto de operadores específicos), spinlocks , semáforos , mutexes , ^{[ 275 ] [ 16 ] : 176–198 [ 276 ]} y algoritmos sin bloqueo (por ejemplo, RCU ). ^{[ 277 ] [ 278 ] [ 279 ]} La mayoría de los algoritmos sin bloqueo se construyen sobre barreras de memoria con el propósito de imponer el orden de la memoria y evitar efectos secundarios no deseados debido a la optimización del compilador . ^{[ 280 ] [ 281 ] [ 282 ] [ 283 ]}

El código PREEMPT_RT incluido en la versión principal de Linux proporciona mutexes RT , un tipo especial de mutex que no deshabilita la expropiación y admite la herencia de prioridad. ^{[ 284 ] [ 285 ]} Casi todos los bloqueos se convierten en bloqueos durmientes cuando se utiliza la configuración para operación en tiempo real. ^{[ 286 ] [ 271 ] [ 285 ]} La herencia de prioridad evita la inversión de prioridad al otorgar a una tarea de baja prioridad que mantiene un bloqueo contencioso la prioridad de un proceso en espera de mayor prioridad hasta que se libere dicho bloqueo. ^{[ 287 ] [ 288 ]}

Linux incluye un validador de bloqueo del kernel llamado Lockdep . ^{[ 289 ] [ 290 ]}

Aunque la gestión de interrupciones podría considerarse una sola tarea, se divide en dos. Esta división se debe a las diferentes restricciones de tiempo y a las necesidades de sincronización de las tareas que la componen. La primera parte consiste en una rutina de servicio de interrupción asíncrona (ISR), conocida en Linux como la mitad superior , mientras que la segunda parte la lleva a cabo uno de los tres tipos de las denominadas mitades inferiores ( softirq , tasklets y colas de trabajo ). ^{[ 16 ] : 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 interrumpe cualquier otra ISR de menor prioridad.

El núcleo de Linux gestiona tanto la memoria física como la virtual. Divide la memoria física en zonas, ^{[ 291 ]} cada una de las cuales tiene un propósito específico.

• ZONE_DMA : esta zona es adecuada para DMA .
• ZONE_NORMAL : para operaciones de memoria normales.
• ZONE_HIGHMEM : parte de la memoria física a la que solo puede acceder el kernel mediante una asignación temporal.

Esas zonas son las más comunes, pero existen otras. ^{[ 291 ]}

Linux implementa memoria virtual con tablas de páginas de 4 o 5 niveles . ^{[ 292 ]} El núcleo no es paginable (lo que significa que siempre reside en la memoria física y no se puede intercambiar al 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 fallos del sistema. ^{[ 16 ] : 20} La memoria de usuario es paginable por defecto, aunque la paginación para áreas de memoria específicas se puede deshabilitar con la familia de llamadas al sistema .mlock()

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

Pequeños bloques de memoria se pueden asignar dinámicamente en el espacio del kernel a través de la familia de kmalloc()API y liberarse con la variante apropiada de kfree(). vmalloc()y kvfree()se utilizan para grandes bloques virtualmente contiguos. alloc_pages()asigna el número deseado de páginas completas.

El kernel solía incluir los asignadores SLAB, SLUB y SLOB como alternativas configurables. ^{[ 295 ] [ 296 ]} El asignador SLOB se eliminó en Linux 6.4 ^{[ 297 ]} y el asignador SLAB se eliminó en Linux 6.8. ^{[ 298 ]} El único asignador restante es SLUB, que busca la simplicidad y la eficiencia, ^{[ 296 ]} es compatible con PREEMPT_RT ^{[ 299 ]} y se introdujo en Linux 2.6.

Dado que Linux admite numerosos sistemas de archivos con diferentes características y funcionalidades, es necesario implementar un sistema de archivos genérico que sea independiente de los sistemas de archivos subyacentes. El sistema de archivos virtual interactúa con otros subsistemas de Linux, el espacio de usuario o las API y abstrae las diferentes implementaciones de los sistemas de archivos subyacentes. VFS implementa llamadas al sistema como create, open, read, writey close. VFS implementa un superbloque genérico ^{[ 300 ]} y un bloque de inodos que es independiente del que tiene el sistema de archivos subyacente.

En este subsistema, los directorios y archivos se representan mediante una struct fileestructura de datos . Cuando el espacio de usuario solicita acceso a un archivo, se devuelve un descriptor de archivo (un valor entero no negativo), pero en el espacio del kernel se trata de una struct fileestructura. Esta estructura almacena toda la información que el kernel conoce sobre un archivo o directorio.

sysfs y procfs son sistemas de archivos virtuales que exponen información de hardware e información de tiempo de ejecución de programas en el espacio de usuario . Estos sistemas de archivos no están presentes en el disco; en su lugar, el kernel los implementa como una función de devolución de llamada o rutina que se ejecuta cuando el espacio de usuario accede a ellos.

Aunque no fue diseñado originalmente para ser portátil , ^{[ 19 ] [ 301 ]} Linux es ahora uno de los núcleos de sistemas operativos más ampliamente portados, ejecutándose en una amplia gama de sistemas, desde la arquitectura ARM hasta las computadoras centrales IBM z/Architecture . El primer porte 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". ^{[ 301 ]} Esto llevó a Torvalds a liderar una importante reestructuración del código para facilitar el porte a más arquitecturas informáticas. El primer Linux que, en un único árbol de código fuente, tenía código para más de i386, soportaba la plataforma DEC Alpha AXP de 64 bits. ^{[ 302 ] [ 303 ] [ 301 ]}

Linux se utiliza como sistema operativo principal en la supercomputadora Summit de IBM . En octubre de 2019, todos los sistemas de la lista TOP500 de las supercomputadoras más rápidas del mundo ejecutaban sistemas operativos basados ​​en el núcleo Linux, ^{[ 73 ]} mientras que la primera supercomputadora basada en Linux apareció en la lista en 1998. ^{[ 304 ]}

Linux también se ha adaptado a varios dispositivos portátiles como el iPhone 3G y el iPod . ^{[ 305 ]}

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. ^{[ 306 ]} La base de datos se crea automáticamente mediante análisis estático del código fuente del núcleo. Posteriormente, 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 usuarios de diversas distribuciones de Linux. ^{[ 307 ]}

Las actualizaciones del kernel se pueden aplicar sin reiniciar el sistema mediante tecnologías de parcheo en vivo como Ksplice , kpatch y kGraft . La compatibilidad inicial con el parcheo en vivo del kernel se integró en la rama principal del kernel de Linux en la versión 4.0, publicada el 12 de abril de 2015. Esta función, conocida como livepatch , utiliza la funcionalidad ftrace del kernel y proporciona una infraestructura común para los parches en caliente suministrados a través de módulos del kernel, junto con interfaces para herramientas de gestión del espacio de usuario. En su implementación inicial en Linux 4.0, la compatibilidad con livepatch se limitaba a la arquitectura x86 y proporcionaba una infraestructura básica en lugar de un modelo completo de consistencia para el parcheo en vivo.

Los errores del núcleo presentan posibles problemas 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 corregido numerosos errores que afectan a la seguridad del sistema. ^{[ 308 ]} Con frecuencia se implementan nuevas características para mejorar la seguridad del núcleo. ^{[ 309 ] [ 310 ]}

Las capacidades (7) ya se han presentado en la sección sobre procesos e hilos. Android las utiliza y systemd proporciona a los administradores un control detallado sobre las capacidades de los procesos. ^{[ 311 ]}

Linux ofrece una gran cantidad de mecanismos para reducir la superficie de ataque del kernel y mejorar la seguridad, conocidos colectivamente como Módulos de Seguridad de Linux (LSM). ^{[ 312 ]} Estos comprenden el módulo Security-Enhanced Linux (SELinux), cuyo código fue desarrollado originalmente y luego publicado por la NSA , ^{[ 313 ]} y AppArmor ^{[ 198 ]} entre otros. SELinux se desarrolla y mantiene activamente en GitHub . ^{[ 197 ]} SELinux y AppArmor brindan soporte a las 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 with Berkeley Packet Filters), que funciona filtrando parámetros y reduciendo el conjunto de llamadas al sistema disponibles para las aplicaciones de espacio de usuario. ^{[ 314 ]}

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

Personalmente, considero que los fallos de seguridad son simplemente "fallos normales". No los oculto, pero tampoco tengo ningún motivo para pensar que sea buena idea rastrearlos y anunciarlos como algo especial... Una de las razones por las que me niego a participar en todo este circo de la seguridad es que creo que glorifica —y, por lo tanto, fomenta— el comportamiento incorrecto. Convierte a los expertos en seguridad en "héroes", como si quienes no se limitan a corregir fallos normales no fueran tan importantes. De hecho, todos los fallos normales y corrientes son mucho más importantes, simplemente porque hay muchos más. No creo que se deba glorificar ni considerar una vulnerabilidad de seguridad espectacular como algo más "especial" que un fallo repentino y espectacular debido a un mal sistema de bloqueo.

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

En 2024, investigadores revelaron que el kernel de Linux contenía una grave vulnerabilidad, CVE-2024-50264, ubicada en el subsistema AF_VSOCK. Este fallo es una vulnerabilidad de uso después de la liberación de memoria, un tipo de problema de corrupción de memoria que ocurre cuando un programa continúa utilizando memoria después de haberla liberado. ^{[ 317 ] [ 318 ]} Estas vulnerabilidades son particularmente peligrosas en el kernel, ya que pueden permitir a los atacantes escalar privilegios. El fallo se resolvió en mayo de 2025. ^{[ 319 ]}

Inicialmente, Torvalds publicó Linux bajo una licencia que prohibía cualquier uso comercial. ^{[ 320 ]} Esto cambió en la versión 0.12 con el cambio a la Licencia Pública General GNU versión 2 (GPLv2). ^{[ 24 ]} Esta licencia permite la distribución y venta de versiones de Linux, posiblemente modificadas o no modificadas, pero requiere que todas esas copias se publiquen bajo la misma licencia y vayan acompañadas de —o que, previa solicitud, se proporcione acceso gratuito a— el código fuente completo correspondiente. ^{[ 321 ]} Torvalds ha descrito la concesión de la licencia GPLv2 a Linux como «lo mejor que he hecho». ^{[ 320 ]}

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

Hubo un debate considerable sobre la facilidad con la que se podría cambiar la licencia para usar versiones posteriores de la GPL (incluida la versión 3), y si este cambio es siquiera deseable. ^{[ 322 ]} El propio Torvalds indicó específicamente al publicarse la versión 2.4.0 que su propio código se publica solo bajo la versión 2. ^{[ 323 ]} Los términos de la GPL establecen que si no se especifica ninguna versión, entonces se puede usar cualquier versión, ^{[ 324 ]} y Alan Cox señaló que muy pocos otros colaboradores de Linux habían especificado una versión particular de la GPL. ^{[ 325 ]}

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 un grupo de personas ajenas... creían que yo personalmente era la excepción porque públicamente no he sido un gran fan de la GPLv3». ^{[ 326 ]} Este grupo de desarrolladores de kernel de alto perfil, incluidos Torvalds, Greg Kroah-Hartman y Andrew Morton , comentaron en los medios de comunicación sobre sus objeciones a la GPLv3. ^{[ 327 ]} Se refirieron a cláusulas relativas a DRM / tivoización , patentes, «restricciones adicionales» y advirtieron sobre una balcanización del «Universo del Código Abierto» por parte de la GPLv3. ^{[ 327 ] [ 328 ]} Torvalds, quien decidió no adoptar la GPLv3 para el kernel de Linux, reiteró su crítica incluso años después. ^{[ 329 ]}

Se debate si algunos módulos de núcleo cargables (LKM, por sus siglas en inglés) deben considerarse obras derivadas según la ley de derechos de autor y, por lo tanto, si están o no sujetos a 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 kernel ^{[ 234 ] [ 235 ]} son ​​obras no derivadas, por lo que Linux proporciona a los administradores del sistema los mecanismos para cargar objetos binarios fuera del árbol en el espacio de direcciones del kernel. ^{[ 15 ]}

Hay algunos módulos cargables fuera del árbol que hacen un uso legítimo de la característica del kernel dma_buf . ^{[ 330 ]} El código compatible con GPL ciertamente puede usarlo. Otro posible caso de uso sería Nvidia Optimus que empareja una GPU rápida con una GPU integrada de Intel, donde la GPU de Nvidia escribe en el framebuffer de Intel cuando está activa. Pero Nvidia no puede usar esta infraestructura porque requiere eludir una regla que solo pueden usar los LKM que también son GPL. ^{[ 236 ]} Alan Cox respondió en LKML , rechazando una solicitud de uno de los ingenieros de Nvidia para eliminar esta imposición técnica de la API. ^{[ 331 ]} Torvalds declaró claramente en LKML que "[Afirmo que los módulos del kernel solo binarios SON derivados "por defecto"". ^{[ 332 ]}

Por otro lado, Torvalds también ha dicho que "[un] área gris en particular es algo como un controlador que fue escrito originalmente para otro sistema operativo (es decir, claramente no es una obra derivada de Linux en su origen). ESA es un área gris, y _esa_ es el área donde personalmente creo que algunos módulos pueden considerarse no obras derivadas simplemente porque no fueron diseñados para Linux y no dependen de ningún comportamiento especial de Linux". ^{[ 333 ]} Los controladores gráficos propietarios , en particular, son objeto de mucha discusión.

Cuando se cargan módulos propietarios en Linux, el kernel se marca a sí mismo como "contaminado" ^{[ 334 ]} y, por lo tanto, los desarrolladores a menudo ignoran los informes de errores de los kernels contaminados.

El kernel oficial, es decir, la rama git de Torvalds en el repositorio kernel.org, contiene blobs binarios publicados bajo los términos de la licencia GNU GPLv2. ^{[ 10 ] [ 15 ]} Linux también puede cargar blobs binarios, firmware propietario, controladores u otros módulos ejecutables desde el sistema de archivos y enlazarlos al espacio del kernel. ^{[ 335 ]}

Cuando sea necesario (por ejemplo, para acceder a los dispositivos de arranque o para mayor velocidad), el firmware puede integrarse en el kernel, es decir, integrarse en vmlinux ; sin embargo, esta no siempre es una opción viable debido a problemas técnicos o legales (por ejemplo, no está permitido hacerlo con firmware que no sea compatible con la GPL, aunque esto es bastante común). ^{[ 336 ]}

Linux es una marca registrada de Linus Torvalds en Estados Unidos, la Unión Europea y otros países. ^{[ 337 ] [ 338 ]} En 1996, se inició una batalla legal por la marca registrada cuando William Della Croce, un abogado que nunca participó en el desarrollo de Linux, comenzó a solicitar el pago de derechos de licencia por el uso de la palabra Linux . Tras demostrarse que la palabra era de uso común mucho antes del supuesto primer uso de Della Croce, la marca registrada fue otorgada a Torvalds. ^{[ 339 ] [ 340 ] [ 341 ]}

En octubre de 2024, durante la invasión rusa de Ucrania , el desarrollador del kernel Greg Kroah-Hartman eliminó de sus funciones como mantenedores a algunos desarrolladores del kernel cuyas direcciones de correo electrónico sugerían una conexión con Rusia. ^{[ 342 ] [ 343 ]} Linus Torvalds respondió que no apoyaba la agresión rusa y que no revertiría el parche, insinuando que los opositores al parche eran trolls rusos . ^{[ 344 ]} James Bottomley, un desarrollador del kernel, emitió una disculpa por el manejo de la situación y aclaró que la acción fue consecuencia de las sanciones estadounidenses contra Rusia . ^{[ 345 ]}