El kernel de Linux es un kernel de sistema operativo gratuito y de código abierto , [12] : 4 monolítico , modular , multitarea , similar a Unix . Fue escrito originalmente en 1991 por Linus Torvalds para su PC basado en i386 , y pronto fue adoptado como el núcleo del sistema operativo GNU , que fue escrito para ser un reemplazo libre de Unix .
Linux se proporciona únicamente bajo la Licencia Pública General GNU versión 2 , pero contiene archivos bajo otras licencias compatibles . [11] Desde finales de la década de 1990, se ha incluido como parte de una gran cantidad de distribuciones de sistemas operativos , muchas de las cuales comúnmente también se denominan Linux .
Linux se implementa en una amplia variedad de sistemas informáticos, como dispositivos integrados , dispositivos móviles (incluido su uso en el sistema operativo Android ), computadoras personales , servidores , mainframes y supercomputadoras . [13] Puede adaptarse a arquitecturas específicas y a varios escenarios de uso utilizando una familia de comandos simples (es decir, sin la necesidad de editar manualmente su código fuente antes de la compilación); [14] [15] [16] los usuarios privilegiados también pueden ajustar los parámetros del kernel en tiempo de ejecución. [17] [18] [19] La mayor parte del código del kernel de Linux está escrito utilizando las extensiones GNU de GCC [12] : 18 [20] al lenguaje de programación C estándar y con el uso de instrucciones específicas de la arquitectura ( ISA ) en partes limitadas del núcleo. Esto produce un ejecutable altamente optimizado ( vmlinux ) con respecto a la utilización del espacio de memoria y los tiempos de ejecución de tareas. [12] : 379–380
Las discusiones de desarrollo del día a día tienen lugar en la lista de correo del kernel de Linux (LKML). Los cambios se rastrean utilizando el sistema de control de versiones git , que fue originalmente creado por Torvalds como un reemplazo de software gratuito para BitKeeper .
.jpg/1280px-LinuxCon_Europe_Linus_Torvalds_03_(cropped).jpg)
En abril de 1991, Linus Torvalds , en ese momento un estudiante de informática de 21 años en la Universidad de Helsinki , Finlandia , comenzó a trabajar en algunas ideas simples para un sistema operativo inspirado en UNIX, para una computadora personal. [21] Comenzó con un conmutador de tareas en lenguaje ensamblador Intel 80386 y un controlador de terminal . [21] El 25 de agosto de 1991, Torvalds publicó lo siguiente en comp.os.minix , un grupo de noticias en Usenet : [22]
Estoy creando un sistema operativo (gratuito) (sólo un hobby, no será grande ni profesional como gnu) para 386(486) clones AT . Esto se viene gestando desde abril y está empezando a prepararse. Me gustaría recibir comentarios sobre las cosas que a la gente le gusta o no le gusta en minix, ya que mi sistema operativo se parece un poco (el mismo diseño físico del sistema de archivos (debido a razones prácticas), entre otras cosas).
Actualmente he portado bash (1.08) y gcc (1.40) y todo parece funcionar. Esto implica que obtendré algo práctico dentro de unos meses [...]
Sí, no tiene ningún código minix y tiene un fs multiproceso. NO es portátil [ sic ] (usa conmutación de tareas 386, etc.), y probablemente nunca admitirá 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 instaló en el servidor FTP "ftp.funet.fi" de la Red de Universidades e Investigación de Finlandia ( FUNET ). Ni siquiera era ejecutable ya que su código aún necesitaba Minix para compilarlo y probarlo. [23]
El 5 de octubre de 1991, Torvalds anunció la primera versión "oficial" de Linux, la versión 0.02. [24] En este punto, Linux podía ejecutar Bash, GCC y algunas otras utilidades GNU: [24] [23]
[Como] mencioné hace un mes, estoy trabajando en una versión gratuita de un modelo Minix para computadoras AT-386. Finalmente ha llegado a la etapa en la que es incluso utilizable (aunque puede que no dependa de lo que usted quiera), y estoy dispuesto a publicar las fuentes para una distribución más amplia. Es solo la versión 0.02... pero ejecuté con éxito bash, gcc, gnu-make, gnu-sed, compress, etc.
Después de eso, a pesar de la funcionalidad limitada de las primeras versiones, Linux rápidamente ganó desarrolladores y usuarios. Mucha gente contribuyó con código al proyecto, incluidos algunos desarrolladores de la comunidad MINIX . [ cita necesaria ] En ese momento, el Proyecto GNU había creado muchos de los componentes necesarios para su reemplazo gratuito de UNIX, el sistema operativo GNU , pero su propio núcleo, GNU Hurd , estaba incompleto. Por esta razón, pronto adoptó también el kernel de Linux. [25] Berkeley Software Distribution aún no se había liberado de las cargas legales y no competía en el espacio por un kernel de sistema operativo gratuito. [26]
Torvalds asignó la versión 0 al kernel para indicar que era principalmente para pruebas y no para uso productivo. [27] La versión 0.11, lanzada en diciembre de 1991, fue el primer Linux autohospedado , ya que podía ser compilado por una computadora que ejecutara el mismo kernel.
Cuando Torvalds lanzó la versión 0.12 en febrero de 1992, adoptó la Licencia Pública General GNU versión 2 (GPLv2) en lugar de su licencia anterior redactada por él mismo, que no permitía la redistribución comercial. [28] A diferencia de Unix , todos los archivos fuente de Linux están disponibles gratuitamente, incluidos los controladores de dispositivos . [29] El éxito inicial de Linux fue impulsado por programadores y evaluadores de todo el mundo. Con el soporte de las API POSIX , a través de la libC que, si es necesario, actúa como punto de entrada al espacio de direcciones del kernel, Linux podría ejecutar software y aplicaciones que habían sido desarrollados para Unix. [30]
El 19 de enero de 1992, se envió la primera publicación al nuevo grupo de noticias alt.os.linux . [31] El 31 de marzo de 1992, el grupo de noticias pasó a llamarse comp.os.linux . [32] 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. [33] El debate Tanenbaum-Torvalds comenzó en 1992 en el grupo Usenet comp.os.minix como una discusión general sobre arquitecturas de kernel. [34] [35]
La versión 0.95 de Linux fue la primera en poder ejecutar el sistema X Window . [36] En marzo de 1994, se lanzó Linux 1.0.0 con 176.250 líneas de código. [37] Fue la primera versión adecuada para su uso en entornos de producción . [27]
Comenzó un sistema de versiones para el kernel con tres o cuatro números separados por puntos donde el primero representaba la versión principal , el segundo era la versión menor y el tercero era la revisión. [12] : 9 En ese momento, los lanzamientos menores con números impares eran para desarrollo y pruebas, mientras que los lanzamientos menores con números pares eran para producción. El cuarto dígito opcional indicaba un conjunto de parches para una revisión. [27] Las versiones de desarrollo se indicaron con el sufijo -rc ("versión candidata").
La numeración de la versión actual es ligeramente diferente a la anterior. Se ha eliminado la numeración par versus impar, y ahora los dos primeros números, tomados en su conjunto, indican una versión principal específica. Si bien el plazo está abierto para el desarrollo de la próxima versión principal , el sufijo -rcN se utiliza para identificar la enésima versión candidata para la próxima versión. [38] 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 realiza una versión estable, su mantenimiento se transfiere al "equipo estable". Las actualizaciones ocasionales de versiones estables se identifican mediante un esquema de tres numeraciones (por ejemplo, 4.13.1, 4.13.2, ..., 4.13.16). [38]
Después de la versión 1.3 del kernel, Torvalds decidió que Linux había evolucionado lo suficiente como para garantizar un nuevo número importante , por lo que lanzó la versión 2.0.0 en junio de 1996. [39] [40] La serie incluyó 41 lanzamientos. La característica principal de 2.0 fue la compatibilidad con multiprocesamiento simétrico (SMP) y la compatibilidad con más tipos de procesadores.
A partir de la versión 2.0, Linux se puede configurar para seleccionar objetivos de hardware específicos y para habilitar funciones y optimizaciones específicas de la arquitectura. [30] La familia de comandos make *config de kbuild se utiliza para habilitar y configurar miles de opciones para crear ejecutables ad hoc del kernel ( vmlinux ) y módulos cargables. [14] [15]
La versión 2.2, lanzada el 20 de enero de 1999, [41] mejoró la granularidad de bloqueo y la gestión de SMP, agregó compatibilidad con m68k , PowerPC , Sparc64 , Alpha y otras plataformas de 64 bits. [42] Además, agregó nuevos sistemas de archivos , incluida la capacidad de solo lectura NTFS de Microsoft . [42] En 1999, IBM publicó sus parches para el código Linux 2.2.13 para el soporte de la arquitectura S/390 . [43]
La versión 2.4.0, lanzada el 4 de enero de 2001, [44] contenía soporte para tarjetas ISA Plug and Play , USB y PC . Linux 2.4 agregó soporte para Pentium 4 e Itanium (este último introdujo el IA64 ISA que fue desarrollado conjuntamente por Intel y Hewlett-Packard para reemplazar al antiguo PA-RISC ) y para el procesador MIPS de 64 bits más nuevo. [45] Desarrollo para 2.4. x cambió un poco en el sentido de que se pusieron a disposición más funciones a lo largo de la serie, incluida la compatibilidad con Bluetooth , Logical Volume Manager (LVM) versión 1, compatibilidad con RAID , InterMezzo y sistemas de archivos ext3 .
La versión 2.6.0 se publicó el 17 de diciembre de 2003. [46] El desarrollo de la 2.6. x cambió aún más para incluir nuevas características a lo largo de la serie. Entre los cambios que se han realizado en la serie 2.6 se encuentran: integración de µClinux en las fuentes principales del kernel, soporte PAE , soporte para varias líneas nuevas de CPU , integración de Advanced Linux Sound Architecture (ALSA) en las fuentes principales del kernel, soporte para hasta 2,32 usuarios (en comparación con 2,16 ) , soporte para hasta 2,29 ID de proceso (solo 64 bits, arquitecturas de 32 bits aún limitadas a 2,15 ) , [47] aumentó sustancialmente el número de tipos de dispositivos y el número de dispositivos de cada tipo, compatibilidad mejorada con 64 bits , compatibilidad con sistemas de archivos que admiten tamaños de archivos de hasta 16 terabytes , preferencia en el kernel , compatibilidad con la biblioteca de subprocesos POSIX nativa (NPTL), integración de Linux en modo de usuario en la línea principal fuentes del kernel, integración de SELinux en las fuentes principales del kernel, soporte para InfiniBand y mucho más.
También es notable la incorporación de una amplia selección de sistemas de archivos a partir del 2.6. Versiones x : ahora, el kernel admite una gran cantidad de sistemas de archivos, algunos que han sido diseñados para Linux, como ext3 , ext4 , FUSE , Btrfs , [48] y otros que son nativos de otros sistemas operativos como JFS , XFS , Minix. , Xenix , Irix , Solaris , System V , Windows y MS-DOS . [49]
En 2005, el equipo estable se formó como respuesta a la falta de un árbol del kernel donde la gente pudiera trabajar en la corrección de errores y continuara actualizando las versiones estables . [50] En febrero de 2008, se creó el árbol linux-next para que sirviera como lugar donde se reunieran los parches que se fusionarían durante el siguiente ciclo de desarrollo. [51] [52] Varios mantenedores de subsistemas también adoptaron el sufijo -next para los á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 . [53]
Linux solía mantenerse sin la ayuda de un sistema automatizado de gestión de código fuente hasta que, en 2002, el desarrollo cambió a BitKeeper . Estaba disponible gratuitamente para los desarrolladores de Linux pero 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 unas semanas y en dos meses se lanzó el primer núcleo oficial creado con él. [54]
Los detalles sobre la historia de la serie del kernel 2.6 se pueden encontrar en los archivos ChangeLog en el área de publicación del código fuente de la serie del kernel 2.6 de kernel.org . [55]
Torvalds celebró el vigésimo aniversario de Linux en julio de 2011 con el lanzamiento de la versión del kernel 3.0.0. [39] Como 2.6 había sido el número de versión durante 8 años, se tuvo que agregar al kernel una nueva personalidad uname26 que informa 3.x como 2.6.40+x para que los programas antiguos funcionaran. [56]
La versión 3.0 se publicó el 22 de julio de 2011. [57] El 30 de mayo de 2011, Torvalds anunció que el gran cambio era "NADA. Absolutamente nada". y preguntó: "... asegurémonos de que la próxima versión no sea sólo un número brillante y completamente nuevo, sino también un buen núcleo". [58] Después de las esperadas 6 a 7 semanas del proceso de desarrollo, se lanzaría cerca del vigésimo aniversario de Linux.
El 11 de diciembre de 2012, Torvalds decidió reducir la complejidad del kernel eliminando el soporte para procesadores i386 , haciendo que la serie de kernel 3.7 sea la última que aún admite el procesador original. [59] [60] La misma serie unificó el soporte para el procesador ARM . [61]
La versión 3.11, lanzada el 2 de septiembre de 2013, [62] agrega muchas características nuevas, como el nuevo indicador O_TMPFILE para reducir las vulnerabilidades de los archivos temporales, administración dinámica de energía experimental de AMD Radeon , sondeo de red de baja latencia y zswap (caché de intercambio comprimido). [63]
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. Se aumentó el número de versión principal para evitar números menores grandes. [57] [64] Los kernels estables 3.xy se lanzaron hasta la versión 3.19 en febrero de 2015.
En abril de 2015, Torvalds lanzó la versión 4.0 del kernel. [39] En 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. [65] 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. [66]
Un total de 1.991 desarrolladores, de los cuales 334 eran colaboradores nuevos, añadieron más de 553.000 líneas de código a la versión 5.8, batiendo el récord que ostentaba anteriormente la versión 4.9. [67]
Según la Encuesta anual de 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 , [68] aunque solo alrededor del 25% desarrolla con sistemas operativos basados en Linux. [69]
La mayoría de los sitios web se ejecutan en sistemas operativos basados en Linux , [70] [71] y las 500 supercomputadoras más potentes del mundo utilizan algún tipo de sistema operativo basado en Linux. [72]
Las distribuciones de Linux combinan el kernel 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 uso compartido en los escritorios es bajo en comparación con otros sistemas operativos.
Android , que representa la mayor parte de la base instalada de todos los sistemas operativos para dispositivos móviles, [73] [74] [75] es responsable del creciente uso del kernel de Linux, [30] junto con su amplio uso en un gran variedad de dispositivos integrados .
Linux es un kernel monolítico con un diseño modular (es decir, puede insertar y quitar módulos del kernel cargables en tiempo de ejecución), [12] : 338 [76] que admite la mayoría de las funciones que antes solo estaban disponibles en kernels de código cerrado de sistemas operativos no libres. El resto del artículo hace uso de la convención de sistemas operativos UNIX y similares a Unix en las páginas oficiales del manual . Los números que siguen al nombre de los comandos, interfaces y otras características tienen el propósito de especificar la sección (es decir, el tipo de componente o característica del sistema operativo) a la que pertenecen (por ejemplo, execve(2) se refiere a una llamada al sistema ). , mientras que exec(3) se refiere a un contenedor de biblioteca de espacio de usuario). La siguiente lista y las secciones siguientes describen una descripción general no exhaustiva del diseño arquitectónico de Linux y de algunas de sus características notables.
La mayoría de los controladores de dispositivos y extensiones del kernel se ejecutan en el espacio del kernel ( 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. [95] [96] Además, X Window System y Wayland , el sistema de ventanas y protocolos de servidor de visualización que la mayoría de la gente usa con Linux, no se ejecutan dentro del kernel. De manera diferente, la interfaz real con las GPU de las tarjetas gráficas es un subsistema interno 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 ejecución y también se pueden adelantar bajo ciertas condiciones para manejar las interrupciones de hardware correctamente y soportar mejor el multiprocesamiento simétrico . [79] Por elección propia, Linux no tiene una interfaz binaria de aplicación de controlador de dispositivo estable . [97]
Linux normalmente hace uso de protección de memoria y memoria virtual y también puede manejar el acceso no uniforme a la memoria , [98] sin embargo el proyecto ha absorbido μClinux , que también hace posible ejecutar Linux en microcontroladores sin memoria virtual. [99]
El hardware está representado 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 . [100] La información de los procesos también se asigna al sistema de archivos a través del directorio /proc . [100]
Linux es un clon de UNIX y apunta al cumplimiento de POSIX y la especificación única de UNIX . [102] El kernel también proporciona llamadas al sistema y otras interfaces específicas de Linux. Para ser incluido en el kernel 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 kernel y el espacio del usuario tiene cuatro grados de estabilidad (estable, de prueba, obsoleto, eliminado); [103] sin embargo, se espera que las llamadas al sistema nunca cambien para no interrumpir los programas del espacio de usuario que dependen de ellas. [104]
Los módulos de kernel cargables (LKM), por diseño, no pueden depender de una ABI estable. [97] Por lo tanto, siempre deben recompilarse cada vez que se instala un nuevo ejecutable del kernel en un sistema; de lo contrario, no se cargarán. Los controladores en el árbol que están configurados para convertirse en una parte integral del ejecutable del kernel ( vmlinux ) están vinculados estáticamente mediante el proceso de construcción.
Tampoco hay garantía de estabilidad de la API en el kernel a nivel fuente [97] y, debido a esto, el código de los controladores de dispositivos , así como el código de cualquier otro subsistema del kernel, deben mantenerse actualizados con la evolución del kernel. Cualquier desarrollador que realice un cambio en la API debe corregir cualquier código que se rompa como resultado de su cambio. [105]
El conjunto de API del kernel de Linux que concierne a las interfaces expuestas a las aplicaciones de usuario se compone fundamentalmente de llamadas al sistema específicas de UNIX y Linux . [106] Una llamada al sistema es un punto de entrada al kernel de Linux. [107] Por ejemplo, entre las específicas de Linux se encuentra la familia de llamadas al sistema clone(2) . [108] La mayoría de las extensiones deben habilitarse definiendo la macro en un archivo de encabezado o cuando se compila el código de usuario. [109]_GNU_SOURCE
Las llamadas al sistema solo se pueden invocar mediante instrucciones de ensamblaje que permiten la transición del 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, solo si son necesarias, [110] pueden ingresar de forma transparente al kernel, que se ejecutará en nombre de la persona que llama. proceso. [106] Para aquellas llamadas al sistema no expuestas por libC, por ejemplo, el mutex rápido del espacio de usuario ( futex ), [111] la biblioteca proporciona una función llamada syscall(2) que puede usarse para invocarlas explícitamente. [112]
Los pseudosistemas de archivos (p. ej., los sistemas de archivos sysfs y procfs ) y los archivos especiales (p. ej. /dev/random, /dev/sda, /dev/tty, y muchos otros) constituyen otra capa de interfaz para las estructuras de datos del núcleo que representan dispositivos hardware o lógicos (software). [113] [114]
Debido a las diferencias que existen entre los cientos de implementaciones distintas 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 se puede ejecutar en diferentes distribuciones de Linux. Este problema se debe principalmente a configuraciones específicas de la distribución y a un conjunto de parches aplicados al código del kernel de Linux, diferencias en las bibliotecas del sistema, servicios (demonios), jerarquías del sistema de archivos y variables de entorno.
El principal estándar relacionado con la compatibilidad binaria y de aplicaciones de las distribuciones de Linux es Linux Standard Base (LSB). [115] [116] Sin embargo, la LSB va más allá de lo que concierne al kernel de Linux, porque también define las especificaciones del escritorio, las bibliotecas X y Qt que poco tienen que ver con él. [117] La versión 5 de LSB se basa en varios estándares y borradores (POSIX, SUS, X/Open, File System Hierarchy (FHS) y otros). [118]
Las partes del LSB en gran medida relevantes para el núcleo son la ABI general (gABI), [119] especialmente la ABI del sistema V [120] [121] y el formato ejecutable y de enlace (ELF), [122] [123] y el ABI específica del procesador (psABI), por ejemplo, la especificación principal para X86-64. [124] [125]
La ABI estándar para cómo los programas de usuario x86_64 invocan llamadas al sistema es cargar el número de syscall en el registro rax y los otros parámetros en rdi , rsi , rdx , r10 , r8 y r9 , y finalmente colocar la instrucción de ensamblaje syscall en el código. [126] [127] [128]
Hay varias API internas del kernel que se utilizan entre los diferentes subsistemas. Algunos están disponibles sólo dentro de los subsistemas del núcleo, mientras que un conjunto algo limitado de símbolos internos (es decir, variables, estructuras de datos y funciones) también está expuesto a módulos cargables dinámicamente (por ejemplo, controladores de dispositivos cargados bajo demanda), ya sea que estén disponibles. exportado con las macros EXPORT_SYMBOL() y EXPORT_SYMBOL_GPL() [130] [131] (esta última reservada a módulos publicados bajo una licencia compatible con GPL). [132]
Linux proporciona API en el kernel que manipulan estructuras de datos (p. ej., listas enlazadas , árboles de base , [133] árboles rojo-negro , [134] colas ) o realizan rutinas comunes (p. ej., 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. [135] [136] [137]
Las API integradas en el kernel incluyen bibliotecas de servicios comunes de bajo nivel utilizados por los controladores de dispositivos:
Los desarrolladores de Linux optaron por no mantener una ABI estable en el kernel. Los módulos compilados para una versión específica del kernel no se pueden cargar en otra versión sin volver a compilarlos, asumiendo que la API del kernel sigue siendo la misma en el nivel fuente; de lo contrario, el código del módulo también deberá modificarse en consecuencia. [97]
Linux crea procesos mediante las llamadas al sistema clone(2) o mediante las más nuevas llamadas al sistema clone3(2) [147] . Dependiendo de los parámetros dados, la nueva entidad puede compartir la mayoría o ninguno de los recursos de la persona que llama. Estas llamadas al sistema pueden crear 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 kernel, aunque ese mismo identificador se llama PID en el espacio de usuario), hasta nuevos subprocesos de ejecución dentro del proceso de llamada (por utilizando el parámetro CLONE_THREAD ). En este último caso, la nueva entidad posee el mismo TGID del proceso de llamada y, en consecuencia, también tiene el mismo PID en el espacio de usuario. [148] [149]
Si el ejecutable está vinculado dinámicamente a bibliotecas compartidas, se utiliza un vinculador dinámico (para objetos ELF, generalmente /lib/ld-linux.so.2 ) para buscar y cargar los objetos necesarios, preparar el programa para ejecutarse y luego ejecutarlo. él. [150]
La biblioteca nativa de subprocesos POSIX , conocida simplemente como NPTL, [151] proporciona la interfaz de subprocesos POSIX estándar ( pthreads ) al espacio de usuario. [152] Siempre que se crea un nuevo hilo usando la interfaz pthread_create(3) POSIX, [153] a la familia clone(2) de llamadas al sistema también se le debe dar la dirección de la función a la que debe saltar el nuevo hilo. El kernel de Linux proporciona los mecanismos futex(7) (acrónimo de "Fast user-space mutexes") para el bloqueo y la sincronización rápidos del espacio de usuario; [154] la mayoría de las operaciones se realizan en el espacio de usuario, pero puede ser necesario comunicarse con el kernel mediante la llamada al sistema futex(2) . [111]
Una categoría muy especial de subprocesos son los llamados subprocesos del núcleo . No deben confundirse con los hilos de ejecución de los procesos del usuario antes mencionados. Los subprocesos del kernel existen sólo en el espacio del kernel y su único propósito es ejecutar tareas del kernel simultáneamente. [155]
De manera diferente, siempre que se crea un proceso independiente, las llamadas al sistema regresan exactamente a la siguiente instrucción del mismo programa, simultáneamente en el proceso principal y en el secundario (es decir, un programa, dos procesos). Diferentes valores de retorno (uno por proceso) permiten al programa saber en cuál de los dos procesos se está ejecutando actualmente. Los programas necesitan esta información porque el proceso hijo, unos pocos pasos después de la duplicación del proceso, generalmente invoca la llamada al sistema execve(2) (posiblemente a través de la familia de funciones contenedoras exec(3) en glibC) y reemplaza el programa que se está ejecutando actualmente. el proceso de llamada con un nuevo programa, con la pila, el montón y los segmentos de datos (inicializados y no inicializados) recién inicializados. [156] Cuando se hace, da como resultado dos procesos que ejecutan dos programas diferentes.
Dependiendo de la identificación de usuario efectiva ( euid ) y de la identificación de grupo efectiva ( egid ), un proceso que se ejecuta con privilegios de usuario cero ( root , el administrador del sistema, posee el identificador 0) puede realizar todo (por ejemplo, eliminar todos los demás procesos). o borrar recursivamente sistemas de archivos completos), en cambio, los procesos de usuario distintos de cero no pueden. capacidades (7) divide los privilegios tradicionalmente asociados con el superusuario en unidades distintas, que pueden ser habilitadas y deshabilitadas de forma independiente por el proceso principal o eliminadas por el propio niño. [157]
El programador de procesos de Linux es modular, en el sentido de que permite diferentes clases y políticas de programación. [158] [159] Las clases de programador son algoritmos de programador conectables que se pueden registrar con el código del programador base. 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 preferencia de usuario como preferencia de kernel completa . [12] : 62–63 La preferencia reduce la latencia , aumenta la capacidad de respuesta, [160] y hace que Linux sea más adecuado para aplicaciones de escritorio y en tiempo real .
Para tareas normales, de forma predeterminada, el kernel utiliza la clase Completely Fair Scheduler (CFS), introducida en la versión 2.6.23 del kernel. [80] Internamente, esta clase de programador predeterminado se define en una macro de un encabezado C como SCHED_NORMAL. En otros núcleos POSIX, una política similar conocida como SCHED_OTHERasigna intervalos de tiempo de CPU (es decir, asigna intervalos absolutos del tiempo del procesador dependiendo de la prioridad predeterminada o calculada dinámicamente de cada proceso). Linux CFS elimina los intervalos de tiempo absolutos y asigna una proporción justa de 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 un tipo de peso que depende de sus prioridades relativas (buenos valores). [12] : 46–50
Con la preferencia del usuario, el programador 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 informáticos para su ejecución (CPU, memoria y más). Lo hace de acuerdo con el algoritmo CFS (en particular, utiliza una variable llamada vruntime para clasificar entidades y luego elige la que tiene el menor vruntime, es decir, la entidad programable que ha tenido la menor proporción de tiempo de CPU), para la política del planificador activo y a las prioridades relativas. [161] Con la preferencia del kernel, el kernel puede adelantarse a sí mismo cuando regresa un controlador de interrupciones, cuando las tareas del kernel se bloquean y cuando un subsistema llama explícitamente a la función Schedule().
El kernel también contiene dos clases de programación en tiempo real compatibles con POSIX [162]SCHED_FIFO denominadas ( primero en entrar, primero en salir en tiempo real ) y SCHED_RR( round-robin en tiempo real ), las cuales tienen prioridad sobre la clase predeterminada. [158] En la versión 3.14 del kernel, lanzada el 30 de marzo de 2014, se agregó una política de programación adicional conocida como SCHED DEADLINE, que implementa el primer algoritmo de fecha límite más temprana (EDF). [163] [164] 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 preferencia y la desactivación de interrupciones (cuando sea posible), PI Mutexes (es decir, primitivas de bloqueo que evitan la inversión de prioridad), [165] [166] soporte para temporizadores de eventos de alta precisión (HPET), actualización de lectura, copia y actualización preventiva (RCU), subprocesos IRQ (forzados) y otras características menores. [167] [168] [169]
En 2023, Peter Zijlstra propuso reemplazar CFS con un programador de primera programación de fecha límite virtual (EEVDF) elegible más temprano, [170] [171] para evitar la necesidad de parches de "latencia agradable" de CFS. [172] El programador EEVDF reemplazó a CFS en la versión 6.6 del kernel de Linux. [173]
El kernel tiene diferentes causas de concurrencia (por ejemplo, interrupciones, mitades inferiores, preferencia de tareas del kernel 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, tener el calificador de tipo C ), Linux proporciona un gran conjunto de herramientas. Consisten en tipos atómicos (que sólo pueden ser manipulados por un conjunto de operadores específicos), spinlocks , semáforos , mutex , [174] [12] : 176–198 [175] y algoritmos sin bloqueo (p. ej., RCU ). [176] [177] [178] La mayoría de los algoritmos sin bloqueo se construyen sobre barreras de memoria con el fin de hacer cumplir el orden de la memoria y evitar efectos secundarios no deseados debido a la optimización del compilador . [179] [180] [181] [182]volatile
PREEMPT_RTEl código incluido en Linux principal proporciona RT-mutex , un tipo especial de Mutex que no desactiva la preferencia y admite herencia de prioridad. [183] [184] Casi todas las cerraduras se cambian a cerraduras inactivas cuando se utiliza la configuración para operación en tiempo real. [185] [169] [184] 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 camarero de mayor prioridad hasta que se libera ese bloqueo. [186] [187]
Linux incluye un validador de bloqueo del kernel llamado Lockdep . [188] [189]
La gestión de las interrupciones , aunque podría verse como un trabajo único, se divide en dos partes diferenciadas. Esta división en dos se debe a las diferentes limitaciones de tiempo y a las necesidades de sincronización de las tareas que componen la gestión. La primera parte está compuesta por una rutina de servicio de interrupción asíncrona que en Linux se conoce como mitad superior , mientras que la segunda parte la lleva a cabo uno de tres tipos de las llamadas mitades inferiores ( softirq , tasklets y colas de trabajo ) . [12] : 133–137 Las rutinas de servicio de interrupciones de Linux se pueden anidar (es decir, una nueva IRQ puede quedar atrapada en un ISR de alta prioridad que se adelanta a cualquier otro ISR de menor prioridad).
La gestión de la memoria en Linux es un tema complejo. En primer lugar, el núcleo no es paginable (es decir, siempre reside en la memoria física y no se puede intercambiar al disco). En el kernel no hay protección de la memoria (no hay señales SIGSEGV , a diferencia del espacio de usuario), por lo que las violaciones de la memoria provocan inestabilidad y fallos del sistema. [12] : 20
Linux implementa memoria virtual con tablas de páginas de 4 y 5 niveles . Como se dijo, siempre solo se puede paginar el espacio de memoria del usuario . Mantiene información sobre cada marco de página de RAM en estructuras de datos apropiadas (de tipo struct page ) que se completan inmediatamente después del arranque y que se conservan hasta el apagado, independientemente de que estén o no asociadas con páginas virtuales. Además, clasifica todos los marcos de página en zonas, según sus limitaciones dependientes de la arquitectura y el uso previsto. Por ejemplo, las páginas reservadas para operaciones DMA están en ZONE_DMA, las páginas que no están asignadas permanentemente a direcciones virtuales están en ZONE_HIGHMEM (en la arquitectura x86_32 esta zona es para direcciones físicas superiores a 896 MB, mientras que x86_64 no la necesita porque x86_64 puede asignar permanentemente direcciones físicas páginas que residen en direcciones superiores), y todo lo que queda (con excepción de otras clasificaciones menos utilizadas) está en ZONE_NORMAL.
Se pueden asignar dinámicamente pequeños fragmentos de memoria a través de la familia de kmalloc()API y liberarlos con la variante adecuada de kfree(). vmalloc()y kvfree()se utilizan para grandes trozos prácticamente contiguos. alloc_pages()asigna el número deseado de páginas completas.
El kernel incluye los asignadores SLAB, SLUB y SLOB como alternativas configurables. [191] [192] SLUB es el más nuevo y también es el asignador predeterminado. Su objetivo es la simplicidad y la eficiencia, [192] y es PREEMPT_RTcompatible. [193] El asignador SLOB se eliminó posteriormente en Linux 6.4, [194] y el asignador SLAB planeaba eliminarse en Linux 6.5, dejando que el único asignador restante fuera SLUB, un asignador que ha estado disponible desde Linux 2.6. [195]
Si bien no fue diseñado originalmente para ser portátil , [22] [196] Linux es ahora uno de los kernels de sistemas operativos más ampliamente adaptados, ejecutándose en una amplia gama de sistemas, desde la arquitectura ARM hasta computadoras mainframe IBM z/Architecture . El primer puerto se realizó en la plataforma Motorola 68000 . Las modificaciones al kernel fueron tan fundamentales que Torvalds vio la versión de Motorola como una bifurcación y un "sistema operativo tipo Linux". [196] Sin embargo, eso llevó a Torvalds a liderar una importante reestructuración del código para facilitar la migración a más arquitecturas informáticas. El primer Linux que, en un único árbol fuente, tenía código para más de i386, soportaba la plataforma DEC Alpha AXP de 64 bits. [197] [198] [196]
Linux se ejecuta como el sistema operativo principal en la Cumbre de IBM ; En octubre de 2019 , las 500 supercomputadoras más rápidas del mundo ejecutan algún sistema operativo basado en el kernel de Linux, [13] un gran cambio con respecto a 1998, cuando se agregó la primera supercomputadora Linux a la lista. [199][update]
Linux también ha sido portado a varios dispositivos portátiles como el iPhone 3G y el iPod de Apple . [200]
En 2007, se inició el proyecto LKDDb para construir una base de datos completa de hardware y protocolos conocidos por los kernels de Linux. [201] La base de datos se construye automáticamente mediante 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 usuarios de varias distribuciones de Linux. [202]
Las actualizaciones sin reinicio pueden incluso aplicarse al kernel mediante el uso de tecnologías de parcheo en vivo como Ksplice , kpatch y kGraft . Las bases minimalistas para la aplicación de parches en vivo al kernel se fusionaron en la línea principal del kernel de Linux en la versión 4.0 del kernel, que se lanzó el 12 de abril de 2015. Esas bases, conocidas como livepatch y basadas principalmente en la funcionalidad ftrace del kernel , forman un núcleo común capaz de admitir parches en caliente. tanto por kGraft como por kpatch, al proporcionar una interfaz de programación de aplicaciones (API) para los módulos del kernel que contienen parches activos y una interfaz binaria de aplicaciones (ABI) para las utilidades de administración del espacio de usuario. Sin embargo, el núcleo común incluido en el kernel 4.0 de Linux solo admite la arquitectura x86 y no proporciona ningún mecanismo para garantizar la coherencia a nivel de funciones mientras se aplican los parches activos. En abril de 2015 [update], se está trabajando en la migración de kpatch y kGraft al núcleo común de parches en vivo proporcionado por la línea principal del kernel de Linux. [203] [204] [205]
Los errores del kernel 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 encontraron y solucionaron numerosos errores que afectaban la seguridad del sistema. [206] Con frecuencia se implementan nuevas características para mejorar la seguridad del kernel. [207] [208]
Las capacidades (7) ya se han introducido en la sección sobre procesos y subprocesos. Android los utiliza y systemd brinda a los administradores un control detallado sobre las capacidades de los procesos. [209]
Linux ofrece una gran cantidad de mecanismos para reducir la superficie de ataque del kernel y mejorar la seguridad, que se conocen colectivamente como Módulos de seguridad de Linux (LSM). [210] Comprenden el módulo Security-Enhanced Linux (SELinux), cuyo código ha sido desarrollado originalmente y luego lanzado al público por la NSA , [211] y AppArmor [94], entre otros. SELinux ahora se desarrolla y mantiene activamente en GitHub . [93] 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 al sistema disponibles para las aplicaciones del usuario. [212]
Los críticos han acusado a los desarrolladores del kernel de encubrir fallos de seguridad, o al menos de no anunciarlos; En 2008, Linus Torvalds respondió a esto con lo siguiente: [213] [214]
Personalmente considero que los errores de seguridad son simplemente "errores normales". No los encubro, pero tampoco tengo ningún motivo para pensar que es una buena idea rastrearlos y anunciarlos como algo especial... una razón por la que me niego a preocuparme por toda la seguridad. El circo es que creo que glorifica (y por tanto fomenta) el comportamiento incorrecto. Convierte a la gente de seguridad en "héroes", como si las personas que no se limitan a corregir errores normales no fueran tan importantes. De hecho, todos los errores normales y aburridos son mucho más importantes, simplemente porque hay muchos más. No creo que un agujero de seguridad espectacular deba glorificarse o preocuparse por ser más "especial" que un accidente espectacular al azar debido a un mal bloqueo.
Las distribuciones de Linux suelen publicar actualizaciones de seguridad para corregir vulnerabilidades en el kernel de Linux. Muchos ofrecen versiones de soporte a largo plazo que reciben actualizaciones de seguridad para una determinada versión del kernel de Linux durante un período prolongado.
La comunidad de desarrolladores del kernel de Linux comprende entre 5.000 y 6.000 miembros. Según el "Estado del desarrollo del kernel de Linux 2017", un estudio publicado por la Fundación Linux, que cubre los compromisos para las versiones 4.8 a 4.13, contribuyeron alrededor de 1500 desarrolladores de entre 200 y 250 empresas en promedio. Los 30 principales desarrolladores contribuyeron con un poco más del 16% del código. En cuanto a las empresas, las principales contribuyentes son Intel (13,1%) y Red Hat (7,2%), Linaro (5,6%), IBM (4,1%), el segundo y quinto lugar lo ocupan las 'ninguna' (8,2%) y ' categorías desconocidas (4,1%). [216]
En lugar de una hoja de ruta, existen directrices técnicas. En lugar de una asignación central de recursos, hay personas y empresas que tienen un interés en el futuro desarrollo del kernel de Linux, de forma bastante independiente entre sí: personas como Linus Torvalds y yo no planificamos la evolución del kernel. No nos sentamos ahí y pensamos en la hoja de ruta para los próximos dos años y luego asignamos recursos a las distintas funciones nuevas. Eso es porque no tenemos ningún recurso. Todos los recursos son propiedad de las distintas corporaciones que utilizan y contribuyen a Linux, así como de los distintos contribuyentes independientes que existen. Son aquellas personas que poseen los recursos quienes deciden...
—Andrew Morton , 2005
Como ocurre con muchos grandes proyectos de software de código abierto, los desarrolladores deben adherirse al Convenio de Colaboradores , un código de conducta destinado a abordar el acoso de los contribuyentes minoritarios. [217] [218] Además, para evitar ofensas, es obligatorio el uso de terminología inclusiva dentro del código fuente. [219]
La comunidad de desarrollo de Linux utiliza Git para gestionar el código fuente . Los usuarios de Git clonan la última versión del árbol de Torvalds con git-clone(1) [220] y la mantienen actualizada usando git-pull(1) . [221] [222] Las contribuciones se envían como parches, en forma de mensajes de texto en el 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 eliminarán y qué otras se agregarán 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 actualizar gradualmente a la siguiente versión. [223] Linux se distribuye también en formatos GNU zip (gzip) y bzip2 .
Un desarrollador que quiere cambiar el kernel de Linux comienza desarrollando y probando ese cambio. Dependiendo de qué tan significativo sea el cambio y 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 único subsistema mantenido por un único mantenedor, estos parches se envían como correos electrónicos al mantenedor del subsistema con la lista de correo adecuada en Cc. El responsable del mantenimiento 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 mantenedor 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 que se consideran lo suficientemente importantes, se enviará una solicitud de extracción de los parches a Torvalds dentro de unos 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 suele durar dos semanas y comienza inmediatamente después del lanzamiento de la versión anterior del kernel. [224] El árbol de fuentes 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 se enumeran en Mantenedores . [225]
Linux está escrito en un lenguaje de programación C especial soportado por GCC , un compilador que extiende el estándar C de muchas maneras, por ejemplo usando secciones en línea de código escritas en lenguaje ensamblador (en la sintaxis "estilo AT&T" de GCC) de la arquitectura de destino. . Desde 2002, todo el código debe cumplir con las 21 reglas que componen el estilo de codificación del kernel de Linux. [226] [227]
En septiembre de 2021, el requisito de la versión GCC para compilar y construir el kernel de Linux aumentó de GCC 4.9 a 5.1, lo que permite 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 . 228] y la migración al estándar se llevará a cabo en marzo de 2022, con el lanzamiento de Linux 5.18. [229]
El soporte inicial para el lenguaje de programación Rust se agregó en Linux 6.1 [5] , que se lanzó en diciembre de 2022, [230] con versiones posteriores del kernel, como Linux 6.2 y Linux 6.3, lo que mejoró aún más el soporte. [231] [232]
La colección de compiladores GNU (GCC o GNU cc) es el compilador predeterminado para las fuentes principales de Linux y se invoca mediante una utilidad llamada make . Luego, el ensamblador GNU (más a menudo llamado GAS o GNU as) genera los archivos objeto del código ensamblador generado por GCC . Finalmente, GNU Linker (GNU ld) se utiliza para producir un archivo de kernel ejecutable vinculado estáticamente llamado vmlinux . Tanto as como ld son parte de GNU Binary Utilities (binutils). Las herramientas mencionadas anteriormente se conocen colectivamente como cadena de herramientas GNU .
GCC fue durante mucho tiempo el único compilador capaz de construir Linux correctamente. En 2004, Intel afirmó haber modificado el kernel para que su compilador de C también fuera capaz de compilarlo. [233] Hubo otro éxito similar en 2009, con una versión 2.6.22 modificada. [234] [235] La compatibilidad con el compilador Intel se eliminó en 2023. [236]
Desde 2010, se han realizado esfuerzos para construir Linux con Clang , un compilador alternativo para el lenguaje C; [237] a partir del 12 de abril de 2014, Clang casi podría compilar el kernel oficial. [238] [239] El proyecto dedicado a este esfuerzo se denomina LLVMLinux por la infraestructura del compilador LLVM sobre la que se construye Clang. [240] LLVMLinux no pretende bifurcar ni Linux ni LLVM, por lo tanto, es un metaproyecto compuesto de parches que eventualmente se envían a los proyectos anteriores. Al permitir que Clang compile Linux, los desarrolladores pueden beneficiarse de tiempos de compilación más cortos. [241]
En 2017, los desarrolladores completaron la actualización de parches para admitir la construcción del kernel de Linux con Clang en la versión 4.15, habiendo respaldado 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 envió con el primer kernel de Linux construido por Clang , [242] aunque existían parches para Pixel (primera generación) . [243] En 2018, ChromeOS pasó a compilar kernels con Clang de forma predeterminada, [244] mientras que Android (sistema operativo) hizo que Clang [245] y el enlazador LLD de LLVM [246] fueran necesarios para las compilaciones de kernel en 2019. Google movió su kernel de producción utilizado en todos sus centros de datos hasta su construcción con Clang en 2020. [247] Hoy en día, el grupo ClangBuiltLinux coordina correcciones tanto para Linux como para LLVM para garantizar la compatibilidad, ambos compuestos por miembros de LLVMLinux y con parches actualizados de LLVMLinux .
Los errores relacionados con el kernel de Linux pueden ser difíciles de solucionar. Esto se debe a la interacción del kernel con el espacio de usuario y el hardware; y también porque pueden deberse a una gama más amplia de motivos en comparación con los de los programas de usuario. Algunos ejemplos de las causas subyacentes son errores semánticos en el código, mal uso de primitivas de sincronización y gestión incorrecta del hardware. [12] : 364
Un informe de un error no grave en el kernel se denomina " ups "; Tales desviaciones del comportamiento correcto del kernel de Linux pueden permitir una operación continua con confiabilidad comprometida. [248]
Un error crítico y fatal se informa mediante la función pánico() . Imprime un mensaje y luego detiene el kernel. [12] : 371
Una de las técnicas más comunes utilizadas para descubrir errores en el código es la depuración mediante impresión . Para este propósito, Linux proporciona una API en el kernel llamada printk () que almacena mensajes en un búfer circular. La llamada al sistema syslog(2) se utiliza para leer y/o borrar el búfer circular de mensajes del kernel y para configurar el nivel de registro máximo de los mensajes que se enviarán a la consola (es decir, uno de los ocho parámetros KERN_* de printk() , que indican la gravedad de la afección informada); normalmente se invoca a través del contenedor glibC klogctl(3) . [249] Los mensajes del kernel también se exportan al área de usuario a través de la interfaz /dev/kmsg [250] (por ejemplo, systemd-journald [251] [252] lee esa interfaz y, de forma predeterminada, agrega los mensajes a /var/log/journal ).
Otra técnica fundamental para depurar un kernel en ejecución es el rastreo. El mecanismo ftrace es un rastreador interno de Linux; se utiliza para monitorear y depurar Linux en tiempo de ejecución y también puede analizar las latencias del espacio del usuario debido al mal comportamiento del kernel. [253] [254] [255] [256] Además, ftrace permite a los usuarios rastrear Linux en el momento del arranque. [257]
kprobes y kretprobes pueden ingresar (como depuradores en el espacio de usuario) en Linux y recopilar información de manera no disruptiva. [258] kprobes se pueden insertar en el código en (casi) cualquier dirección, mientras que kretprobes funcionan en el retorno de la función. Los uprobes tienen propósitos similares pero también tienen algunas diferencias en el uso y la implementación. [259]
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 a depurar mediante un cable serie o Ethernet . [260]
El proyecto del kernel de Linux integra código nuevo de forma continua. El software incorporado al proyecto debe funcionar y compilarse sin errores. A cada subsistema del kernel se le asigna un mantenedor que es responsable de revisar los parches según los estándares del código del kernel y mantiene una cola de parches que se pueden enviar a Linus Torvalds dentro de una ventana de fusión de varias semanas. Torvalds fusiona los parches en el código fuente de la versión estable anterior del kernel de Linux, creando la versión candidata -rc para el próximo kernel estable. Una vez que se cierra la ventana de combinación, solo se aceptan correcciones al nuevo código en la versión de desarrollo. La versión de desarrollo -rc del kernel pasa por pruebas de regresión y una vez que Torvalds y los mantenedores del subsistema del kernel lo consideran estable, se lanza un nuevo kernel de Linux y el proceso de desarrollo comienza de nuevo. [261]
Los desarrolladores que se sientan tratados injustamente pueden informarlo al Consejo Asesor Técnico de la Fundación Linux . [262] En julio de 2013, el responsable del mantenimiento 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 son a menudo directos, groseros o brutales". su trabajo hecho". [263] 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 encargado del mantenimiento del controlador del 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. [264]
Laurent Pinchart pidió a los desarrolladores comentarios sobre su experiencia con la comunidad del kernel en la Conferencia Europea de Linux Embedded 2017. Las cuestiones planteadas se discutieron unos días después en la Cumbre de Mantenedores. Shuah Khan, el mantenedor del marco de autoprueba del kernel, se hizo eco de las preocupaciones sobre la falta de coherencia en la forma en que los mantenedores respondieron a los parches enviados por los desarrolladores. Torvalds sostuvo que nunca habría coherencia en el manejo de parches porque diferentes subsistemas del núcleo han adoptado, con el tiempo, diferentes procesos de desarrollo. Por lo tanto, se acordó que cada mantenedor del subsistema del núcleo documentaría las reglas para la aceptación de parches. [265]
El árbol Git de Linus Torvalds que contiene el kernel de Linux se conoce como Linux principal . Cada versión estable del kernel se origina en el árbol principal, [266] y se publica con frecuencia en kernel.org . Mainline Linux sólo tiene un soporte sólido para un pequeño subconjunto de los muchos dispositivos que ejecutan Linux. El soporte no principal lo proporcionan proyectos independientes, como Yocto o Linaro , pero en muchos casos se necesita el kernel del proveedor del dispositivo. [267] El uso de un kernel de proveedor probablemente requiera un paquete de soporte de placa .
Mantener un árbol de kernel fuera de Linux principal ha demostrado ser difícil. [268]
Mainlining se refiere al esfuerzo de agregar soporte para un dispositivo al núcleo principal, [269] mientras que anteriormente solo había soporte en una bifurcación o ningún soporte en absoluto. Esto generalmente incluye agregar controladores o archivos de árbol de dispositivos . Cuando esto finaliza, la función o solución de seguridad se considera principal . [270]
El mantenedor de la rama estable, Greg Kroah-Hartman , ha aplicado el término similar a Linux a las bifurcaciones del kernel posteriores realizadas por proveedores que agregan millones de líneas de código al kernel principal. [271] En 2019, Google declaró que quería utilizar el kernel de Linux principal en Android para reducir la cantidad de bifurcaciones del kernel. [272] El término similar a Linux también se ha aplicado al subconjunto del kernel de Linux integrable , que no incluye el kernel de Linux principal completo sino un pequeño subconjunto modificado del código. [273]
Hay ciertas comunidades que desarrollan kernels 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. [274] Algunos sistemas operativos desarrollados para teléfonos móviles utilizaron inicialmente 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 kernel: [275] [276]
Esto significa que cualquier controlador escrito para plataformas de hardware Android no puede fusionarse en el árbol del kernel principal porque depende del código que solo se encuentra en el árbol del kernel de Google, lo que hace que no se pueda compilar en el árbol kernel.org. Debido a esto, Google ahora ha impedido que una gran cantidad de controladores de hardware y código de plataforma se fusionen en el árbol principal del kernel. Crear efectivamente una rama del kernel en la que ahora confían varios proveedores diferentes. [277]
— Greg Kroah-Hartman , 2010
Hoy en día, Android utiliza un Linux personalizado [278] donde se implementan cambios importantes en los controladores de dispositivos, pero se requieren algunos cambios en el código del núcleo central. Los desarrolladores de Android también envían parches para Linux oficial que finalmente pueden iniciar el sistema operativo Android. Por ejemplo, un Nexus 7 puede arrancar y ejecutar la línea principal de Linux. [278]
En una presentación de 2001 en el Museo de Historia de la Computación , Linus Torvalds dijo lo siguiente en respuesta a una pregunta sobre las distribuciones de Linux que utilizan exactamente las mismas fuentes del kernel o no:
No lo son... bueno, lo son, y no lo son. No existe un núcleo único. Cada distribución tiene sus propios cambios. Esto ha estado sucediendo desde prácticamente el primer día. No sé si recordarán que Yggdrasil era conocido por tener cambios bastante extremos en el kernel e incluso hoy en día todos los principales proveedores tienen sus propios ajustes porque tienen una parte del mercado que les interesa 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 punto de tener un sistema abierto. Entonces, 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 kernel estándar, 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 de registro integrado en el kernel estándar no fue porque amo a Hans Reiser. Fue porque SUSE comenzó a distribuir ReiserFS como su kernel estándar, lo que me dijo "ok". En realidad, esto está en uso de producción. La gente normal está haciendo esto. Deben saber algo que yo no sé. Entonces, en un sentido muy real, lo que hacen muchas casas de distribución es que son parte de este "hagamos nuestra propia sucursal" y "hagamos nuestros cambios en esto". Y gracias a la GPL, puedo tomar las mejores porciones. [279]
— Linus Torvalds , 2001
Ha habido varios conflictos notables entre los desarrolladores del kernel de Linux. Ejemplos de tales conflictos son:
Destacados desarrolladores del kernel de Linux han sido conscientes de la importancia de evitar conflictos entre desarrolladores. [292] Durante mucho tiempo no hubo un código de conducta para los desarrolladores del kernel debido a la oposición de Linus Torvalds . [293] Sin embargo, el 8 de marzo de 2015 se introdujo un Código de Conflictos del Kernel de Linux . [294] 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. [295] [296] El 30 de noviembre de 2018, cumpliendo con el Código de Conducta , Jarkko Sakkinen de Intel envió parches reemplazando las instancias de "joder" que aparecen en los comentarios del código fuente con versiones adecuadas centradas en la palabra "abrazo". [297]
En 2021 [update], 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 forma parte del "núcleo" (directorios arch, kernel y mm), mientras que el 60% son controladores.
¡Linux es evolución, no diseño inteligente!
— Linus Torvalds , 2005 [298] [299] [300]
El coste de volver a desarrollar la versión 2.6.0 del kernel de Linux en un entorno de desarrollo propietario tradicional se ha estimado en 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 mes-persona de COCOMO . [301] En 2006, un estudio financiado por la Unión Europea situó el coste de redesarrollo de la versión 2.6.8 del kernel más alto, en 882 millones de euros (1.140 millones de dólares, 744 millones de libras esterlinas). [302]
Este tema fue retomado en octubre de 2008 por Amanda McPherson, Brian Proffitt y Ron Hale-Evans. Utilizando la metodología de David A. Wheeler, estimaron que el redesarrollo del kernel 2.6.25 ahora cuesta 1.300 millones de dólares (parte de un total de 10.800 millones de dólares para redesarrollar Fedora 9). [303] Nuevamente, García-García y Alonso de Magdaleno de la Universidad de Oviedo (España) estiman que el valor añadido anualmente al kernel fue de unos 100 millones de euros entre 2005 y 2007 y 225 millones de euros en 2008; costaría también más de mil millones de euros ( alrededor de 1.400 millones de dólares en febrero de 2010) para desarrollarse en la Unión Europea. [304]
A partir del 7 de marzo de 2011 , utilizando las LOC[update] (líneas de código) actuales de un kernel Linux 2.6.x y las cifras salariales con los cálculos de David A. Wheeler, costaría aproximadamente 3 mil millones de dólares (alrededor de 2,2 mil millones de euros) volver a desarrollar el kernel Linux como sigue haciéndose más grande. Un cálculo actualizado al 26 de septiembre de 2018 , utilizando 20.088.609 LOC (líneas de código) actuales para el kernel de Linux 4.14.14 y el salario promedio nacional actual de un programador en EE. UU. de $75.506 muestra que reescribir costaría aproximadamente $14.725.449.000 dólares (£11.191.341.000). el código existente. [305][update]
La última versión del kernel y las versiones anteriores del kernel se mantienen por separado. La mayoría de las últimas versiones del kernel fueron supervisadas por Linus Torvalds. [306]
La comunidad de desarrolladores del kernel de Linux mantiene un kernel estable aplicando correcciones para errores de software que se han descubierto durante el desarrollo del kernel estable posterior. Por lo tanto, www.kernel.org siempre incluirá dos núcleos estables. El próximo kernel estable de Linux se lanza ahora sólo entre 8 y 12 semanas después. Por lo tanto, los mantenedores del kernel de Linux han designado algunas versiones estables del kernel como a largo plazo ; estos kernels de Linux con soporte a largo plazo se actualizan con correcciones de errores durante dos o más años. [307] A partir de febrero de 2022 [update], hay seis kernels de Linux a largo plazo: 5.15.23, 5.10.100, 5.4.179, 4.19.229, 4.14.266 y 4.9.301. [308] La lista completa de lanzamientos se encuentra en el historial de versiones del kernel de Linux .
La mayoría de los usuarios de Linux ejecutan un kernel proporcionado por su distribución de Linux . Algunas distribuciones incluyen núcleos "vainilla" o "estables". Sin embargo, varios proveedores de distribuciones de Linux (como Red Hat y Debian ) mantienen otro conjunto de ramas del kernel de Linux que están integradas en sus productos. Por lo general, se actualizan a un ritmo más lento en comparación con la rama "vainilla" y generalmente incluyen todas las correcciones de la rama "estable" relevante, pero al mismo tiempo también pueden agregar soporte para controladores o funciones que no se habían lanzado en la versión "vainilla" en la que el proveedor de distribución comenzó a basar su sucursal.
Inicialmente, Torvalds lanzó Linux bajo una licencia que prohibía cualquier uso comercial. [309] Esto se cambió en la versión 0.12 mediante un cambio a la Licencia Pública General GNU versión 2 (GPLv2). [28] Esta licencia permite la distribución y venta de versiones posiblemente modificadas y no modificadas de Linux, pero requiere que todas esas copias se publiquen bajo la misma licencia y vayan acompañadas de (o que, previa solicitud, se brinde acceso gratuito a) la fuente completa correspondiente. código. [310] Torvalds ha descrito la concesión de licencias de Linux bajo la GPLv2 como "lo mejor que he hecho". [309]
El kernel de Linux tiene licencia explícita bajo la Licencia Pública General GNU versión 2 únicamente (solo GPL-2.0) con una excepción explícita de llamada al sistema (Linux-syscall-note), [6] [9] [10] sin ofrecer al licenciatario la opción de Elija cualquier versión posterior, que es una extensión GPL común. El código aportado debe estar disponible bajo una licencia compatible con GPL . [11] [105]
Hubo un debate considerable sobre la facilidad con la que se podía cambiar la licencia para utilizar versiones posteriores de la GPL (incluida la versión 3) y si este cambio era siquiera deseable. [311] El propio Torvalds indicó específicamente tras el lanzamiento de la versión 2.4.0 que su propio código se publica sólo en la versión 2. [312] Sin embargo, los términos de la GPL establecen que si no se especifica ninguna versión, se puede utilizar cualquier versión. , [313] y Alan Cox señalaron que muy pocos otros contribuyentes de Linux habían especificado una versión particular de la GPL. [314]
En septiembre de 2006, una encuesta realizada a 29 programadores clave del kernel indicó que 28 preferían la GPLv2 al borrador de GPLv3 entonces vigente. Torvalds comentó: "Creo que varios forasteros... creían que yo personalmente era el extraño porque públicamente no he sido un gran admirador de la GPLv3". [315] 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. [316] Se refirieron a cláusulas relativas a DRM / tivoización , patentes, "restricciones adicionales" y advirtieron sobre una balcanización del "Universo Open Source" por la GPLv3. [316] [317] Linus Torvalds, quien decidió no adoptar la GPLv3 para el kernel de Linux, reiteró sus críticas incluso años después. [318]
Se debate si algunos módulos del kernel cargables (LKM) deben considerarse obras derivadas según la ley de derechos de autor y, por lo tanto, si entran o no bajo los términos de la GPL.
De acuerdo con las reglas de licencia, los LKM que utilizan sólo un subconjunto público de las interfaces del kernel [130] [131] son trabajos no derivados, por lo que Linux brinda a los administradores de sistemas los mecanismos para cargar objetos binarios fuera del árbol en el espacio de direcciones del kernel. . [11]
Hay algunos módulos cargables fuera del árbol que hacen un uso legítimo de la característica del kernel dma_buf . [319] 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 framebuffer de Intel cuando está activo. Pero Nvidia no puede usar esta infraestructura porque requiere eludir una regla que solo pueden usar los LKM que también son GPL. [132] Alan Cox respondió en LKML , rechazando una solicitud de uno de sus ingenieros para eliminar esta aplicación técnica de la API. [320] Torvalds declaró claramente en el LKML que "[yo] afirmo que los módulos del kernel sólo binarios SON derivados "por defecto"'". [321]
Por otro lado, Torvalds también ha dicho que "[un] área gris en particular es algo así como un controlador que fue escrito originalmente para otro sistema operativo (es decir, claramente no es 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 considerarse no trabajos derivados simplemente porque no fueron diseñados para Linux y no dependen de ningún comportamiento especial de Linux". [322] Los controladores de gráficos propietarios , en particular, son objeto de intensa discusión.
Siempre que se cargan módulos propietarios en Linux, el kernel se marca a sí mismo como "contaminado" [323] y, por lo tanto, los desarrolladores a menudo ignoran los informes de errores de kernels contaminados.
El kernel oficial, que es la rama Linus git 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, luego puede cargarlos y vincularlos al espacio del kernel. [324]
Cuando sea necesario (por ejemplo, para acceder a dispositivos de arranque o para aumentar la velocidad), el firmware se puede incorporar al kernel, esto 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). [325]
Linux es una marca registrada de Linus Torvalds en los Estados Unidos, la Unión Europea y algunos otros países. [326] [327] Una batalla legal sobre la marca comenzó en 1996, cuando William Della Croce, un abogado que nunca estuvo involucrado en el desarrollo de Linux, comenzó a solicitar tarifas de licencia por 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 fue otorgada a Torvalds. [328] [329] [330]
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
{{cite book}}: CS1 maint: location missing publisher (link)
