Home MundoTec Software Código fuente Tutorial / pdf Minijuegos
Cerrar

Tutorial El Núcleo de Linux

Tutorial EL NÚCLEO LINUX. Algunas secciones de esta versión on-line, que se encuentran en la versión PDF, han sido suprimidos.







Introducción

El núcleo (en inglés kernel) del sistema GNU/Linux (al que habitualmente denominaremos Linux) [Vasb], es el corazón del sistema: se encarga de arrancarlo y, una vez este es ya utilizable por las aplicaciones y los usuarios, se encarga de gestionar los recursos de la máquina, en forma de gestión de la memoria, del sistema de ficheros, de las operaciones de entrada/salida y de los procesos y su intercomunicación.

Su origen se remonta al año 1991, cuando en agosto, un estudiante finlandés llamado Linus Torvalds anunció en una lista de noticias, que había creado su propio núcleo de sistema operativo, funcionando conjuntamente con software GNU, y lo ofrecía a la comunidad de desarrolladores para que lo probara y sugiriera mejoras para hacerlo más utilizable. Este es el origen del núcleo del sistema operativo que más tarde se llamaría GNU/Linux.

Una de las particularidades de Linux es que, siguiendo la filosofía de software libre, se nos ofrece el código fuente del núcleo del propio sistema operativo (del kernel), de manera que es una herramienta perfecta para la educación, en temas de análisis y diseño de sistemas operativos.

La otra ventaja principal es que, disponiendo de los archivos fuente, podemos recompilarlos, para adaptarlos mejor a nuestro sistema, y como veremos en el módulo “Sintonización, optimización y alta disponibilidad”, configurarlos para dar un mejor rendimiento al sistema.

En este módulo veremos cómo manejar este proceso de preparación de un núcleo para nuestro sistema: cómo, partiendo de los archivos fuente, podemos obtener una nueva versión del núcleo adaptada a nuestro sistema. Veremos cómo se desarrolla la configuración, la posterior compilación y la realización de pruebas con el nuevo núcleo obtenido.

Además, veremos cómo el núcleo ha ido añadiendo toda una serie de características a lo largo de su evolución, que lo han convertido en competitivo frente a otros sistemas. En especial, observaremos algunas características de la virtualización que nos ofrecen con soporte desde el núcleo.


1. El núcleo del sistema GNU/Linux

El núcleo o kernel es la parte básica de cualquier sistema operativo, y sobre él descansa el código de los servicios fundamentales para controlar el sistema completo. Básicamente, su estructura puede separarse en una serie de componentes, o módulos de gestión orientados a:

Gestión de procesos: qué tareas se van a ejecutar y en qué orden y con qué prioridad. Un aspecto importante es la planificación de la CPU: ¿cómo se optimiza el tiempo de la CPU para ejecutar las tareas con el mayor rendimiento o interactividad posible con los usuarios?

Intercomunicación de procesos y sincronización: ¿cómo se comunican tareas entre sí, con qué diferentes mecanismos y cómo pueden sincronizarse grupos de tareas?

Gestión de entrada/salida (E/S): control de periféricos y gestión de recursos asociados.

Gestión de memoria: optimización del uso de la memoria, sistema de paginación y memoria virtual.

Gestión de ficheros: cómo el sistema controla y organiza los ficheros presentes en el sistema, y accede a los mismos.

Nucleo Linux


En los sistemas privativos, el núcleo, o kernel, está perfectamente “oculto” bajo las capas del software del sistema operativo, y el usuario final no tiene una perspectiva clara de qué es ese núcleo ni tiene tampoco ninguna posibilidad de cambiarlo u optimizarlo, si no es por el uso de esotéricos editores de “registros” internos, o programas especializados de terceros (normalmente de alto coste). Además, el núcleo suele ser único, es el que proporciona el fabricante, el cual se reserva el derecho de introducir las modificaciones que quiera y cuando quiera, así como tratar los errores que aparezcan en plazos no estipulados, mediante actualizaciones que nos ofrece como “parches” de errores (o grupos de ellos denominados comúnmente service packs).

Uno de los principales problemas de esta aproximación es precisamente la disponibilidad de estos parches: disponer de las actualizaciones de los errores a su debido tiempo y, si se trata de problemas de seguridad, todavía con más razón, ya que hasta que no estén corregidos no podemos garantizar la seguridad del sistema para problemas ya conocidos. Muchas organizaciones, grandes empresas, gobiernos, instituciones científicas y militares no pueden depender de los caprichos de un fabricante para solucionar los problemas de sus aplicaciones críticas.

En este caso, el núcleo Linux ofrece una solución de código abierto, con los consecuentes permisos de modificación, corrección, posibilidad de generación de nuevas versiones y actualizaciones de forma rápida, por parte de cualquiera que quiera y tenga los conocimientos adecuados para realizarlo. Esto permite a los usuarios críticos controlar mejor sus aplicaciones y el propio sistema, y poder montar sistemas con el propio sistema operativo “a la carta”, personalizado al gusto de cada uno. También permite disponer, a su vez, de un sistema operativo con código abierto, desarrollado por una comunidad de programadores coordinados mediante Internet y accesible ya sea para educación, por disponer del código fuente y abundante documentación, o para la producción final de los sistemas GNU/Linux adaptados a necesidades individuales o de un determinado colectivo.

Al disponer del código fuente, se pueden aplicar mejoras y soluciones de forma inmediata, a diferencia del software privativo, donde debemos esperar a las actualizaciones del fabricante. Podemos, además, personalizar el núcleo tanto como necesitemos, requisito esencial, por ejemplo, en aplicaciones de alto rendimiento, críticas en el tiempo o en soluciones con sistemas empotrados (como dispositivos móviles).

A continuación repasamos un poco la historia del núcleo [Kera, Kerb]. El núcleo Linux lo comenzó a desarrollar un estudiante finlandés llamado Linus Torvalds, en 1991, con la intención de realizar una versión parecida a MINIX (versión para PC de UNIX) para el procesador 386 de Intel. La primera versión publicada oficialmente fue la de Linux 1.0 en marzo de 1994, en la cual se incluía sólo la ejecución para la arquitectura i386 y soportaba máquinas de un solo procesador. Linux 1.2 fue publicado en marzo de 1995 y fue la primera versión en dar cobertura a diferentes arquitecturas, como Alpha, Sparc y Mips. Linux 2.0, en junio de 1996, añadió más arquitecturas y fue la primera versión en incorporar soporte multiprocesador (SMP). En Linux 2.2, de enero de 1999, se incrementaron las prestaciones de soporte SMP de manera significativa, y se añadieron controladores para gran cantidad de hardware. En la 2.4, en enero del 2001, se mejoró el soporte SMP, se incorporaron nuevas arquitecturas y se integraron controladores para dispositivos USB, PC Card (PCMCIA de los portátiles), parte de PnP (plug and play), soporte de RAID y volúmenes, etc. En la rama 2.6 del núcleo (diciembre de 2003), se mejoró sensiblemente el soporte SMP, se introdujo una mejor respuesta del sistema de planificación de CPU, el uso de hilos (threads) en el núcleo, mejor soporte de arquitecturas de 64 bits, soporte de virtualización y una mejor adaptación a dispositivos móviles.

Respecto al proceso de desarrollo, desde su creación por Linus Torvalds en 1991 (versión 0.01), el núcleo lo ha seguido manteniendo él mismo, pero a medida que su trabajo se lo permitía y a medida que el núcleo maduraba (y crecía), se ha visto obligado a mantener las diferentes versiones estables del núcleo gracias a diferentes colaboradores, mientras que Linus continua (en la medida de lo posible) desarrollando y recopilando aportaciones para la última versión de desarrollo del núcleo. Los colaboradores principales en estas versiones han sido:

2.0 David Weinehall.
2.2 Alan Cox (también desarrolla y publica parches para la mayoría de versiones).
2.4 Marcelo Tosatti.
2.5 Linus Torvalds.
2.6 Greg Kroah-Hartman (versiones estables) / Linus Torvalds, Andrew Morton (releases de desarrollo).


Para ver un poco la complejidad del núcleo de Linux, veamos un poco de su historia resumida en diferentes versiones y en el tamaño respectivo del código fuente. Por ejemplo, en 09-1991 la version 0.01 tenia 10 mil lineas de código, en 03-1994 la version 1.0 tenia 176 mil líneas de código, la version 2.2 de 01-1999 tenia 1800 mil lineas de código y la versión 2.6 de 12-2003 tenia 5930 mil lineas de código.

Como podemos comprobar, hemos pasado de unas diez mil líneas a seis millones en las primeras versiones de la rama 2.6; las últimas versiones de esta rama se mueven entre los diez a quince millones de líneas.

En estos momentos el desarrollo continúa en la rama 2.6.x del núcleo, la última versión estable, que incluyen la mayoría de distribuciones como versión principal (algunas todavía incluyen algunas 2.4.x, pero 2.6.x suele ser la opción por defecto en la instalación).

Aunque ahora la rama principal sea la 2.6.x, cierto conocimiento de las anteriores versiones es imprescindible, ya que con facilidad podemos encontrar máquinas con distribuciones antiguas que no se hayan actualizado, que es posible que debamos mantener o realizar un proceso de migración a versiones más actuales.

En la rama del 2.6, durante su desarrollo se aceleraron de forma significativa los trabajos del núcleo, ya que tanto Linus Torvalds como Andrew Mor- ton (que mantienen varias de las ramas de Linux 2.6 en desarrollo) se incorporaron (durante 2003) al Open Source Developement Laboratory (OSDL), un consorcio de empresas cuyo fin es promocionar el uso de Open Source y GNU/Linux en la empresa (en el consorcio se encuentran, entre otras muchas empresas con intereses en GNU/Linux: HP, IBM, Sun, Intel, Fujitsu, Hitachi, Toshiba, Red Hat, Suse, Transmeta, etc.). En esos momentos se dio una situación interesante, ya que el consorcio OSDL hizo de patrocinador de los trabajos, tanto para el mantenedor de la versión estable del núcleo (Andrew) como para el de la de desarrollo (Linus), trabajando a tiempo completo en las versiones y en los temas relacionados. Linus se mantiene independiente, trabajando en el núcleo, mientras Andrew se fue a trabajar a Google, donde continuaba a tiempo completo sus desarrollos, realizando parches con diferentes y nuevas aportaciones al núcleo, en la que se conoce como rama de desarrollo -mm. Despues de cierto tiempo, OSDL se reconvirtió en la fundación The Linux Foundation.

Hay que tener en cuenta que con las versiones actuales del núcleo se ha alcanzado ya un alto grado de desarrollo y madurez, lo que hará que cada vez se amplíe más el tiempo entre la publicación de las versiones estables, no así de las revisiones parciales o de desarrollo, aspecto en el que los mantenedores esperan una nueva versión cada 2 o 3 meses.

Además, otro factor a considerar es el tamaño y el número de personas que están trabajando en el desarrollo actual. En un principio había unas pocas personas que tenían un conocimiento global del núcleo entero, mientras que hoy en día tenemos un importante número de personas que lo desarrollan (se cree que cerca de varios miles) con diferentes contribuciones, aunque el grupo duro se estima en unas pocas docenas de desarrolladores.

También cabe tener en cuenta que la mayoría de desarrolladores (de los miles) solo tienen unos conocimientos parciales del núcleo y, ni todos trabajan simultáneamente, ni su aportación es igual de relevante (algunas aportaciones solo corrigen errores sencillos). En el otro extremo, son unas pocas personas (como los mantenedores) las que disponen de un conocimiento total del núcleo. Esto supone que se puedan alargar los desarrollos y que se tengan que depurar las aportaciones, para comprobar que no entren en conflicto entre ellas, o que se deba escoger entre posibles alternativas de prestaciones.

Respecto a la numeración de las versiones del núcleo de Linux, cabe tener en cuenta los aspectos siguientes:

1) Hasta la rama del núcleo 2.6.x, las versiones del núcleo Linux se regían por una división en dos series: una era la denominada “experimental” (con numeración impar en la segunda cifra, como 1.3.xx, 2.1.x o 2.5.x) y la otra era la de producción (serie par, como 1.2.xx, 2.0.xx, 2.2.x, 2.4.x y más). La serie experimental eran versiones que se movían rápidamente y se utilizaban para probar nuevas prestaciones, algoritmos, controladores de dispositivo, etc. Por la propia naturaleza de los núcleos experimentales, podían tener comportamientos impredecibles, como pérdidas de datos, bloqueos aleatorios de la máquina, etc. Por lo tanto, no estaban destinadas a utilizarse en máquinas para la producción, a no ser que se quisiese probar una característica determinada (con los consecuentes peligros).

Los núcleos de producción (serie par) o estables eran los núcleos con un conjunto de prestaciones bien definido, con un número bajo de errores conocidos y controladores de dispositivos probados. Se publicaban con menos frecuencia que los experimentales y existían variedad de versiones, unas de más o menos calidad que otras. Las distribuciones GNU/Linux se suelen basar en una determinada versión del núcleo estable, no necesariamente el último núcleo de producción publicado.

2) En la numeración actual del núcleo Linux (utilizada en la rama 2.6.x), se siguen conservando algunos aspectos básicos: la versión viene indicada por unos números X.Y.Z, donde normalmente X es la versión principal, que representa los cambios importantes del núcleo; Y es la versión secundaria, y habitualmente implica mejoras en las prestaciones del núcleo: Y es par en los núcleos estables e impar en los desarrollos o pruebas; Z es la versión de construcción, que indica el número de la revisión de X.Y, en cuanto a parches o correcciones hechas.

Los distribuidores no suelen incluir la última versión del núcleo, sino la que ellos hayan probado con más frecuencia y puedan verificar que es estable para el software y componentes que ellos incluyen. Partiendo de este esquema de numeración clásico (que se siguió durante las ramas 2.4.x hasta los inicios de la 2.6), hubo algunas modificaciones para adaptarse al hecho de que el núcleo (rama 2.6.x) se vuelve más estable (fijando X.Y a 2.6) y cada vez las revisiones son menores (por significar un salto de versión de los primeros números), pero el desarrollo continuo y frenético sigue.

En los últimos esquemas se llega a introducir cuartos números, para especificar Z cambios menores, o diferentes posibilidades de la revisión (con diferentes parches añadidos que corrigen fallos). La versión así definida con cuatro números es la que se considera estable (stable). También se usan otros esquemas para las diversas versiones de prueba (normalmente no recomendables para entornos de producción), como sufijos -rc (release candidate), -mm que son núcleos experimentales con gran introducción de parches que suponen nuevas prestaciones adicionales como pruebas de diferentes técnicas novedosas, o los -git que son una especie de “foto” diaria del desarrollo del núcleo. Estos esquemas de numeración están en constante cambio para adaptarse a la forma de trabajar de la comunidad del núcleo y a sus necesidades para acelerar el desarrollo.

3) Para obtener el último núcleo publicado (que normalmente se denomina vanilla o pristine), hay que acudir al archivo de núcleos Linux (disponible en http://www.kernel.org) o al mirror local (en España http://www.es.kernel.org). También podrán encontrarse aquí algunos parches al núcleo original, que corrigen errores detectados a posteriori de la publicación del núcleo.

Algunas de las características técnicas del núcleo Linux que podríamos destacar son:

Núcleo de tipo monolítico: básicamente es un gran programa creado como una unidad, pero conceptualmente dividido en varios componentes lógicos.

Tiene soporte para carga y descarga de porciones del núcleo bajo demanda; estas porciones se llaman módulos y suelen ser características del núcleo o controladores de dispositivo.

Hilos de núcleo: Para el funcionamiento interno se utilizan varios hilos (threads en inglés) de ejecución internos al núcleo, que pueden estar asociados a un programa de usuario o bien a una funcionalidad interna del núcleo. En Linux no se hacía un uso intensivo de este concepto en origen, pero ha pasado a ser un concepto fundamental para el rendimiento, en especial debido a la aparición de las CPU multicore. En las diferentes revisiones de la rama 2.6.x se ofreció un mejor soporte, y gran parte del núcleo se ejecuta usando diversos hilos de ejecución.

Soporte de aplicaciones multihilo: soporte de aplicaciones de usuario de tipo multihilo (multithread), ya que muchos paradigmas de computación de tipo cliente/servidor necesitan servidores capaces de atender múltiples peticiones simultáneas dedicando un hilo de ejecución a cada petición o grupo de ellas. Linux tiene una biblioteca propia de hilos que puede usarse para las aplicaciones multihilo, con las mejoras que se introdujeron en el núcleo, que también han permitido un mejor uso para implementar bibliotecas de hilos para el desarrollo de aplicaciones.

El núcleo es de tipo no apropiativo (nonpreemptive): esto implica que dentro del núcleo no pueden pararse llamadas a sistema (en modo supervisor) mientras se está resolviendo la tarea de sistema, y cuando ésta acaba, se prosigue la ejecución de la tarea anterior. Por lo tanto, el núcleo dentro de una llamada no puede ser interrumpido para atender a otra tarea. Normalmente, los núcleos apropiativos están asociados a sistemas que trabajan en tiempo real, donde debe permitirse lo anterior para tratar eventos críticos. Hay algunas versiones especiales del núcleo de Linux para tiempo real (ramas -rt, de realtime), que permiten esto por medio de la introducción de unos puntos fijos donde las tareas del núcleo pueden interrumpirse entre si. También se ha mejorado especialmente este concepto en la rama 2.6.x del núcleo, que en algunos casos permite interrumpir algunas tareas del núcleo, reasumibles, para tratar otras, prosiguiendo posteriormente su ejecución. Este concepto de núcleo apropiativo también puede ser útil para mejorar tareas interactivas, ya que si se producen llamadas costosas al sistema, pueden provocar retardos en las aplicaciones interactivas.

Soporte para multiprocesador, tanto lo que se denomina multiprocesamiento simétrico (SMP) como multicore. Este concepto suele englobar máquinas que van desde el caso simple de 2 hasta 64 CPU colocadas en diferentes zócalos físicos de la máquina. Este tema se ha puesto de especial actualidad con las arquitecturas de tipo multicore, que permiten de 2 a 8 o más núcleos de CPU en un mismo zócalo físico, en máquinas accesibles a los usuarios domésticos. Linux puede usar múltiples procesadores, donde cada procesador puede manejar una o más tareas. Pero originalmente había algunas partes del núcleo que disminuían el rendimiento, ya que están pensadas para una única CPU y obligan a parar el sistema entero en determinados bloqueos. SMP es una de las técnicas más estudiadas en la comunidad del núcleo de Linux, y se han obtenido mejoras importantes en la rama 2.6. Del rendimiento SMP depende en gran medida la adopción de Linux en los sistemas empresariales, en la faceta de sistema operativo para servidores.

Sistemas de ficheros: el núcleo tiene una buena arquitectura de los sistemas de ficheros, ya que el trabajo interno se basa en una abstracción de un sistema virtual (VFS, virtual file system), que puede ser adaptada fácilmente a cualquier sistema real. Como resultado, Linux es quizás el sistema operativo que más sistemas de ficheros soporta, desde su propio ext2 inicial, hasta msdos, vfat, ntfs, sistemas con journal como ext3, ext4, ReiserFS, JFS(IBM), XFS(Silicon), NTFS, iso9660 (CD), udf, etc. y se van añadiendo más en las diferentes revisiones del núcleo.


Otras características menos técnicas (un poco de marketing) que podríamos destacar:

1) Linux es gratuito: junto con el software GNU, y el incluido en cualquier distribución, podemos tener un sistema tipo UNIX completo prácticamen- te por el coste del hardware; y por la parte de los costes de la distribución GNU/Linux, podemos obtenerla prácticamente gratis. Pero no está de más pagar por una distribución completa, con los manuales y apoyo técnico, a un coste menor comparado con lo que se paga por algunos sistemas privativos, o contribuir con la compra al desarrollo de las distribuciones que más nos gusten o nos sean prácticas.

2) Linux es personalizable: la licencia GPL nos permite leer y modificar el código fuente del núcleo (siempre que tengamos los conocimientos adecuados).

3) Linux se ejecuta en hardware antiguo bastante limitado; es posible, por ejemplo, crear un servidor de red con un 386 con 4 MB de RAM (hay distribuciones especializadas en bajos recursos).

4) Linux es un sistema de altas prestaciones: el objetivo principal en Linux es la eficiencia y se intenta aprovechar al máximo el hardware disponible.

5) Alta calidad: los sistemas GNU/Linux son muy estables, con una baja proporción de fallos, y reducen el tiempo dedicado a mantener los sistemas.

6) El núcleo es bastante reducido y compacto: es posible colocarlo, junto con algunos programas fundamentales en un solo disco de 1,44 MB (existen varias distribuciones de un solo disquete con programas básicos).

7) Linux es compatible con una gran parte de los sistemas operativos, puede leer ficheros de prácticamente cualquier sistema de ficheros y puede comunicarse por red para ofrecer y recibir servicios de cualquiera de estos sistemas. Además, también con ciertas bibliotecas puede ejecutar programas de otros sistemas (como MS-DOS, Windows, BSD, Xenix, etc.) en la arquitectura x86 o bien virtualizar máquinas completas.

8) Linux dispone de un amplísimo soporte: no hay ningún otro sistema que tenga la rapidez y cantidad de parches y actualizaciones que Linux, ni en los sistemas privativos. Para un problema determinado, hay infinidad de listas de correo y foros que en pocas horas pueden permitir solucionar cualquier problema. El único problema está en los controladores de hardware reciente, que muchos fabricantes todavía se resisten a proporcionar, si no es para sistemas privativos. Pero esto está cambiando poco a poco, y varios de los fabricantes más importantes de sectores como tarjetas de vídeo (NVIDIA, ATI) e impresoras (Epson, HP) comienzan ya a proporcionar los controladores para sus dispositivos, bien sean de código abierto, o binarios usables por el núcleo.


2. Personalización o actualización del núcleo

Como usuarios o administradores de sistemas GNU/Linux, debemos tener en cuenta las posibilidades que nos ofrece el núcleo para adaptarlo a nuestras necesidades y equipos.

Normalmente, construimos nuestros sistemas GNU/Linux a partir de la instalación en nuestros equipos de alguna de las distribuciones de GNU/Linux, ya sean comerciales como Red Hat, Mandriva o Suse, o “comunitarias” como Debian y Fedora.

Estas distribuciones aportan, en el momento de la instalación, una serie de núcleos Linux binarios ya preconfigurados y compilados, y normalmente tenemos que elegir qué núcleo del conjunto de los disponibles se adapta mejor a nuestro hardware. Hay núcleos genéricos para una arquitectura, para un modelo de procesador o bien orientados disponer de una serie de recursos de memoria, otros que ofrecen una mezcla de controladores de dispositivos, posibilidades de virtualización, etc.

Otra opción de instalación suele ser la versión del núcleo. Normalmente las distribuciones usan una versión para instalación que consideran lo suficientemente estable y probada como para que no cause problemas a los usuarios. Por ejemplo, a día de hoy muchas distribuciones vienen con una versión de la rama 2.6.x del núcleo por defecto, que se consideraba la versión más estable del momento en que salió la distribución. En algunos casos en el momento de la instalación puede ofrecerse la posibilidad de usar como alternativa versiones más modernas, con mejor soporte para dispositivos más modernos (de última generación), pero quizás no tan probadas.

Los distribuidores suelen, además, modificar el núcleo para mejorar el comportamiento de su distribución o corregir errores que han detectado en el nú- cleo en el momento de las pruebas. Otra técnica bastante común en las distribuciones comerciales es deshabilitar prestaciones problemáticas, que pueden causar fallos o que necesitan una configuración especifica de la máquina, o bien una determinada prestación no se considera lo suficientemente estable para incluirla activada.

Esto nos lleva a considerar que, por muy bien que un distribuidor haga el trabajo de adaptar el núcleo a su distribución, siempre nos podemos encontrar con una serie de problemas u objetivos que no podemos realizar con la situación actual:

El núcleo no está actualizado a la última versión estable disponible; no se dispone de soporte para algunos dispositivos modernos.

El núcleo estándar no dispone de soporte para los dispositivos que tenemos, porque no han sido habilitados.

Los controladores que nos ofrece un fabricante necesitan una nueva versión del núcleo o modificaciones.

A la inversa, el núcleo es demasiado moderno, tenemos hardware antiguo que ya no tiene soporte en los últimos núcleos.

El núcleo, tal como está, no obtiene las máximas prestaciones de nuestros dispositivos.

Algunas aplicaciones que queremos usar requieren soporte de un núcleo nuevo o de algunas de sus prestaciones.

Queremos estar a la última, nos arriesgamos, instalando últimas versiones del núcleo Linux.

Nos gusta investigar o probar los nuevos avances del núcleo o bien queremos tocar o modificar el núcleo.

Queremos programar un controlador para un dispositivo no soportado.

Etc.

Por estos y otros motivos podemos no estar contentos con el núcleo que tenemos. Se nos plantean entonces dos posibilidades: actualizar el núcleo binario de la distribución o bien personalizarlo a partir de los paquetes fuente.

Vamos a ver algunas cuestiones relacionadas con las diferentes opciones y qué suponen:

1) Actualización del núcleo de la distribución. El distribuidor normalmente publica también las actualizaciones que van surgiendo del núcleo. Cuando la comunidad Linux crea una nueva versión del núcleo, cada distribuidor la une a su distribución y hace las pruebas pertinentes. Después del periodo de prueba, se identifican posibles errores, los corrige y produce la actualización del núcleo pertinente respecto a la que ofrecía en los CD de la distribución. Los usuarios pueden descargar la nueva revisión de la distribución del sitio web, o bien actualizarla mediante algún sistema automático de paquetes vía repositorio de paquetes. Normalmente, se verifica qué versión tiene el sistema, se descarga el núcleo nuevo y se hacen los cambios necesarios para que la siguiente vez el sistema funcione con el nuevo núcleo, y se mantiene la versión antigua por si hay problemas.

Si nuestro hardware tampoco viene habilitado por defecto en la nueva versión, estamos en la misma situación. O sencillamente, si queremos la última versión, este proceso no nos sirve.

2) Personalización del núcleo. En este caso, iremos a los paquetes fuente del núcleo y adaptaremos “a mano” el hardware o las características deseadas. Pasaremos por un proceso de configuración y compilación de los paquetes fuente del núcleo para, finalmente, crear un núcleo binario que instalaremos en el sistema, y tenerlo, así, disponible en el siguiente arranque del sistema.

También aquí podemos encontrarnos con dos opciones más: o bien por de- fecto obtenemos la versión “oficial” del núcleo (kernel.org) o bien podemos acudir a los paquetes fuente proporcionados por la propia distribución. Hay que tener en cuenta que distribuciones como Debian y Fedora hacen un trabajo importante de adecuación del núcleo y de corrección de errores del que afectan a su distribución, con lo cual podemos, en algunos casos, disponer de correcciones adicionales al código original del núcleo. Otra vez más los paquetes fuente ofrecidos por la distribución no tienen porqué corresponder a la última versión estable publicada.


3. Proceso de configuración y compilación

La personalización del núcleo es un proceso costoso, necesita amplios conocimientos del proceso a realizar y, además, es una de las tareas críticas, de la cual depende la estabilidad del sistema, por la propia naturaleza del núcleo, puesto que es su elemento central.

Cualquier error de procedimiento puede comportar la inestabilidad o la pérdida del sistema. Por lo tanto, no está de más realizar cualquier tarea de copia de seguridad de los datos de usuarios, datos de configuraciones que hayamos personalizado o, si disponemos de dispositivos adecuados, una copia de seguridad completa del sistema. También es recomendable disponer de algún disquete de arranque (o distribución LiveCD con herramientas de rescate) que nos sirva de ayuda por si surgen problemas, o bien un disquete/CD/archivo de rescate (rescue disk) que la mayoría de distribuciones permiten crear desde los CD de la distribución (o directamente proporcionan alguno como CD de rescate para la distribución). Actualmente muchos de los LiveCD de las distribuciones ya proporcionan herramientas de rescate suficientes para estas tareas, aunque también existen algunas distribuciones especializadas para ello.

Sin ánimo de exagerar, casi nunca aparecen problemas si se siguen los pasos adecuadamente, se tiene conciencia de los pasos realizados y se toman algunas precauciones. Evidentemente, ante sistemas en producción, siempre es importante tomar las medidas de precaución y hacer las copias de seguridad necesarias.

Vamos a ver el proceso necesario para instalar y configurar un núcleo Linux. En los subapartados siguientes, examinamos:

1) El caso de las versiones antiguas 2.4.x.
2) Algunas consideraciones sobre la migración a las 2.6.x partiendo de 2.4.x.
3) Detalles específicos de las versiones 2.6.x.
4) Un caso particular para la distribución Debian, que dispone de un sistema propio (Debian way) de compilación más flexible.

Respecto las versiones 2.4.x, mantenemos en este módulo la explicación por razones históricas, ya que las distribuciones actuales prácticamente ya no las ofrecen, pero debemos considerar que en más de una ocasión nos veremos obligados a migrar un determinado sistema a nuevas versiones, o bien a mantenerlo en las antiguas, debido a incompatibilidades o existencia de hardware antiguo no soportado.

Los conceptos generales del proceso de compilación y configuración se explicarán en el primer subapartado (2.4.x), ya que la mayoría de ellos son genéricos, y observaremos posteriormente las diferencias respecto de las nuevas versiones. Aun así, cada subapartado puede examinarse de manera autosuficiente.

También hay que añadir que, con las últimas distribuciones, cada vez es más casual la necesidad de reconstruir o recompilar el propio núcleo, debido, entre otras consideraciones, a que:

Antiguamente la mayoría de los controladores estaban integrados en el núcleo y había que recompilarlo por completo si queríamos incluir o excluir un controlador determinado. Hoy en día, como veremos en el apartado 5, pueden recompilarse los controladores o módulos concretos, no el núcleo en si mismo.
Para sintonizar el núcleo, antiguamente había que recompilarlo. En muchos casos (no todos) puede realizarse la sintonización de algunos elementos del núcleo mediante el acceso al sistema de ficheros /proc o /sys.
En algunos casos de distribuciones comerciales (versiones empresariales para las que se paga soporte), los núcleos y el sistema completo están soportados por el equipo de la distribución, y a veces pueden perderse las licencias de soporte o las garantías por realizar cambios de este estilo.
Por otro lado, las distribuciones tienen una velocidad bastante rápida en cuanto a integrar parches y nuevos núcleos a medida que se generan.

Por contra, una personalización del núcleo, mediante recompilación, nos puede permitir:

Escoger qué partes incluir o excluir del núcleo, dando un soporte concreto a una plataforma o un hardware muy concreto. Esto es imprescindible si estamos, por ejemplo, en situaciones de hardware empotrado (embedded).
Sintonizar, de esta última manera, el consumo de memoria u otros recursos para adaptarse mejor a recursos limitados (CPU, memoria, disco, etc.).
Versiones concretas de las distribuciones implican usar ciertas versiones específicas del núcleo. En muchos casos no podemos obtener nuevas ac- tualizaciones del núcleo si no actualizamos la distribución concreta completamente.
Probar versiones de núcleo todavía no disponibles en las distribuciones. Aunque hay cierta rapidez de integración de los nuevos núcleos, se puede tardar semanas o meses en disponer de los nuevos núcleos vía distribución. Por otra parte, algunas distribuciones son muy conservadoras en cuanto a la versión de núcleo utilizada, y hay que esperar varias versiones completas de la distribución (un periodo largo de tiempo) para llegar a una versión concreta de núcleo.
Probar versiones beta, o parches de núcleo, con el objetivo de integrarlo rápidamente en algún sistema con problemas concretos, o bien sencillamente por cuestiones de evaluación de las nuevas posibilidades o de un mejor rendimiento.
Participar directamente en el desarrollo del núcleo, estudiando posibles mejoras del código actual, proponiendo y probando propuestas concretas. Es típico de algunos componentes, así como estudiar diferentes estrategias de planificación de CPU, de gestión de memoria, mejorar parámetros del núcleo o colocar alguna prestación nueva a algún sistema de ficheros.

En los siguientes subapartados veremos las diferentes posibilidades en cuanto a la configuración y recompilación de las diferentes ramas de desarrollo del núcleo Linux, que no están en la versión on-line y encontrarás en la versión PDF.


4. Aplicación de parches al núcleo

En algunos casos también puede ser habitual la aplicación de parches (patches) al núcleo.

Los parches suelen necesitarse cuando un hardware especial necesita alguna modificación en el núcleo, o se han detectado algunos errores (bugs) posteriores a alguna distribución concreta de una versión del núcleo, o bien quiere añadirse una nueva prestación sin generar una versión de núcleo nueva. Para corregir el problema (o añadir la nueva prestación), se suele distribuir un parche en lugar de un nuevo núcleo completo. Cuando ya existen varios de estos parches, se unen con diversas mejoras del núcleo anterior para formar una nueva versión del mismo. En todo caso, si tenemos hardware problemático o el error afecta a la funcionalidad o a la estabilidad del sistema y no podemos esperar a la siguiente versión del núcleo, será necesario aplicar el/los parche(s).

El parche se suele distribuir en un fichero comprimido tipo bz2 (bunzip2, aunque también puede encontrarse en gzip con extensión .gz), como por ejemplo podría ser:

patchxxxx-2.6.xx-pversion.bz2

donde xxxx suele ser algún mensaje sobre el tipo o finalidad del parche. 2.6.xx sería la versión del núcleo al cual se le va a aplicar el parche, y pversion haría referencia a la versión del parche, del que también pueden existir varias. Hay que tener en cuenta que estamos hablando de aplicar parches a los paquetes fuente del núcleo (normalmente instalados, como vimos, en /usr/src/linux o directorio similar del usuario usado en la compilación del núcleo).

Una vez dispongamos del parche, tendremos que aplicarlo. Veremos el proceso a seguir en algún fichero Readme que acompaña al parche, pero generalmente el proceso sigue los pasos (una vez comprobados los requisitos previos) de descomprimir el parche en el directorio de los ficheros fuente y aplicarlo sobre las fuentes del núcleo, como por ejemplo:

cd /usr/src/linux (o /usr/src/linux-2.6.xx o la versión que sea).
bunzip2 patch-xxxxx-2.6.xx-version.bz2
patch -p1 < patch-xxxxx-2.6.xx-version

También puede aplicarse previamente con la opción patch -p1 -dry-run que solo procede a realizar un primer test, para asegurarnos previamente que no haya alguna condición de error cuando se sustituya el código. Si no hay error, volvemos a aplicar entonces sin la opción de test.

Posteriormente, una vez aplicado el parche, tendremos que recompilar el núcleo para volverlo a generar.

Los parches pueden obtenerse de diferentes lugares. Lo más normal es encontrarlos en el sitio de almacén de los núcleos vanilla (http://www.kernel.org), que tiene un archivo completo de los mismos. Determinadas comunidades Linux (o usuarios individuales) también suelen ofrecer algunas correcciones, pero es mejor buscar en los sitios estándar para asegurar un mínimo de confianza en estos parches y evitar problemas de seguridad con posibles parches “piratas”. Otra vía es el fabricante de hardware que puede ofrecer ciertas modificaciones del núcleo (o de controladores en forma de módulos dinámicos de núcleo) para que funcionen mejor sus dispositivos (un ejemplo conocido es NVIDIA y sus controladores Linux propietarios para sus tarjetas gráficas).

Por último, señalaremos que muchas distribuciones de GNU/Linux (Fedo- ra/Red Hat, Mandriva) ya ofrecen núcleos parcheados por ellos mismos y sistemas para actualizarlos (algunos incluso de forma automática, como en el caso de Fedora/Red Hat y Debian). Normalmente, en sistemas de producción es más recomendable seguir las actualizaciones del fabricante, aunque éste no ofrecerá necesariamente el último núcleo publicado, sino el que crea más estable para su distribución, con el inconveniente de perder prestaciones de última generación o alguna novedad en las técnicas incluidas en el núcleo. Un ejemplo, en el caso de distribución de parches, podría ser el caso de la distribución Debian para los paquetes fuente de núcleo proporcionados por la distribución. Debian produce revisiones del núcleo aplicando diferentes series de parches sobre los fuentes originales, así su núcleo ofrecido en repositorios no es el original, sino el resultado de aplicar una serie de parches. Un ejemplo de proceso, para obtener un núcleo con diferentes parches aplicados, podría ser el siguiente (donde xx es la revisión de la rama 2.6 usada por Debian):

# apt-get install linux-source-2.6.xx

Para desempaquetar el núcleo (lo encontraremos en /usr/src/):

# apt-get install linux-patch-debian-2.6.xx
# cd linux-source-2.6.xx
# /usr/src/kernel-patches/all/2.6.xx/apply/debian 2.6.xx-1

Esta última parte nos instala el conjunto de parches que Debian ha generado para la versión fuente del núcleo usado y, en el ultimo comando, nos permite volver a una revisión Debian concreta del núcleo (lo que se suele denominar un patchlevel de los fuentes del núcleo). Así, por ejemplo, si la revisión del núcleo es 2.6.xx-2, el comando anterior volvería (proceso denominado rollback) los fuentes del núcleo a la anterior versión patchlevel 2.6.xx-1. Así podemos escoger una versión del núcleo según el subconjunto de parches aplicados.

Por último, cabe comentar la incorporación de una tecnología reciente al uso de parches en Linux, Ksplice, que permite a un sistema Linux añadir parches al núcleo sin necesidad de parar y rearrancar el sistema. Básicamente, Ksplice determina a partir de los paquetes fuente cuáles son los cambios introducidos por un parche o una serie de ellos, y comprueba en memoria cómo afectan a la imagen del núcleo en memoria que se encuentra ejecutándose. Se intenta entonces parar la ejecución en el momento en que no existan dependencias de tareas que necesiten las partes del núcleo a parchear. Entonces se procede a cambiar, en el código objeto del núcleo, las funciones afectadas, apuntando a las nuevas funciones con el parche aplicado y modificando datos y estructuras de memoria que tengan que reflejar los cambios. Actualmente es un producto comercial, pero algunas distribuciones de comunidad ya lo están incluyendo debido al soporte gratuito que se ofrece para algunas. En los casos de producción en empresas, con servidores en los que es importante no disminuir el tiempo de servicio, puede ser una tecnología crítica para usar, altamente recomendable tanto para disminuir el tiempo de pérdida de servicio como para minimizar incidentes de seguridad que afecten al núcleo.

Básicamente ofrecen un servicio denominado Ksplice Uptrack que es una especie de actualizador de parches para el núcleo en ejecución. La gente de Ksplice sigue el desarrollo de los parches fuente del núcleo, los prepara en forma de paquetes que puedan incorporarse a un núcleo en ejecución y los hace disponibles en este servicio uptrack. Una herramienta gráfica gestiona estos paquetes y los hace disponibles para la actualización durante la ejecución.


5. Módulos del núcleo

El núcleo es capaz de cargar dinámicamente porciones de código (módulos) bajo demanda, para complementar su funcionalidad (se dispone de esta posibilidad desde la versión 1.2 del núcleo). Por ejemplo, los módulos pueden añadir soporte para un sistema de ficheros o para dispositivos de hardware específicos. Cuando la funcionalidad proporcionada por el módulo no es necesaria, el módulo puede ser descargado y así liberar memoria.

Normalmente bajo demanda, el núcleo identifica una característica no presente en el núcleo en ese momento, contacta con un hilo (thread) del núcleo denominado kmod (en las versiones del núcleo 2.0.x el daemon era llamado kerneld) y este ejecuta un comando modprobe para intentar cargar el módulo asociado a partir de una cadena con el nombre de módulo o bien de un identificador genérico. Esta información en forma de alias entre el nombre y el identificador se consulta en el fichero /etc/modules.conf.

A continuación se busca en /lib/modules/version-kernel/modules.dep para saber si hay dependencias con otros módulos. Finalmente, con el comando insmod se carga el módulo desde /lib/modules/version_kernel/ (el directorio estándar para los módulos), la version-kernel es la versión del núcleo actual y se utiliza el comando uname -r para determinarla. Por tanto, los módulos en forma binaria están relacionados con una versión concreta del núcleo, y suelen colocarse en /lib/modules/version-kernel. Los módulos se reconocen como archivos dentro de la estructura de este directorio, con .ko como extensión de archivo.

En general, el administrador debe conocer cómo se cargan los módulos en el sistema. La mayor parte de veces por el proceso anterior, los módulos de la mayoría del hardware y necesidades concretas son detectados automáticamente en arranque o por demanda de uso y cargados en el momento correspondiente. En muchos casos no deberemos realizar ningún proceso como administradores. Pero en algunos casos, habrá que preparar alguna sintonización del proceso o de los parámetros de los módulos, o en algunos casos añadir nuevos módulos ya en forma binaria o por compilación a partir de los fuentes.

Si hay que realizar alguna compilación de módulos a partir de sus fuentes, se tiene que disponer de los paquetes fuente y/o headers de la versión del núcleo al cual está destinado.

Hay unas cuantas utilidades que nos permiten trabajar con módulos (solían aparecer en un paquete de software llamado modutils, que se reemplazó por module-init-tools para la gestión de módulos de la rama 2.6.x):

lsmod: Podemos ver los módulos cargados en el núcleo (la información se obtiene del pseudofichero /proc/modules). Se listan los nombres, las dependencias con otros (entre corchetes, [ ]), el tamaño del módulo en bytes y el contador de uso del módulo; esto permite descargarlo si la cuenta es cero.
modprobe: Intenta la carga a mano de un módulo y de sus dependencias.
insmod: Carga un módulo determinado.
depmod: Analiza dependencias entre módulos y crea un fichero de dependencias.
rmmod: Saca un módulo del núcleo.
depmod: Usado para generar el fichero de dependencias de los módulos, que se encuentra en /lib/modules/version-kernel/modules.dep y que incluye las dependencias de todos los módulos del sistema. Si se instalan nuevos módulos de núcleo, es interesante ejecutar manualmente este comando para actualizar las dependencias. También se suelen generar automáticamente al arrancar el sistema.
Se pueden usar otros comandos para depuración o análisis de los módulos, como modinfo, que lista informaciones asociadas al módulo (como licencias, descripción, uso y dependencias), o ficheros /proc/kallsyms, que nos permiten examinar los símbolos exportados por los módulos.

Ya sea por el mismo núcleo o por el usuario manualmente con insmod, normalmente para la carga se especificará el nombre del módulo y, opcionalmente, determinados parámetros; por ejemplo, en el caso de dispositivos suele ser habitual especificar las direcciones de los puertos de E/S o bien los recursos de IRQ o DMA. Por ejemplo:

insmod soundx io=0x320 irq=5

La carga general de módulos, en función del momento y la forma, puede hacerse manualmente, como hemos comentado, mediante initrd/initramfs o por medio de udev.

En el caso de initrd/initramfs, cuando el sistema arranca, se necesitan inmediatamente algunos módulos, para acceder al dispositivo y al sistema de ficheros raíz del sistema, por ejemplo controladores específicos de disco o tipos de sistemas de ficheros. Estos módulos, necesarios se cargan mediante un sistema de ficheros especial en RAM denominado initrd/initramfs. Dependiendo de la distribución GNU/Linux se utilizan estos términos de forma indiferente, aunque en algunos casos se han producido cambios a lo largo de la vida de la distribución. Por convención, suele denominarse a este elemento como filesystem RAM inicial, y se le refiere comunmente como initramfs.

El sistema inicial de ficheros en RAM, initramfs, es cargado por el bootloader en la especificación de la entrada correspondiente a la carga del núcleo correspondiente (por ejemplo en la línea/opción initrd de la entrada correspondiente de Grub).

En la mayoría de distribuciones, ya sea con el núcleo distribuido originalmente o bien con nuestra configuración del núcleo, suele crearse un initramfs inicial. En todo caso, si dependiendo de la distribución no se produce (puede no ser necesario), entonces podemos crearlo y sintonizarlo manualmente. El comando mkinitramfs permite crearlo a partir de sus opciones genéricas, que no suelen cambiarse y que se pueden configurar en el archivo /etc/initramfs-tools/initramfs.conf y, específicamente, los módulos que se cargarán en inicio automáticamente, que podemos encontrarlos en /etc/initramfs-tools/modules.

Un mkinitramfs -o new_initrd_file nos permitirá crearlo, y normalmente podemos proceder a copiarlo en el directorio /boot para hacerlo accesible al bootloader usado. Por ejemplo, mediante un cambio en Grub de su fichero de configuración /boot/grub/menu.lst, modificando la línea de initrd oportuna. En cualquier caso, siempre es interesante establecer en el bootloader una configuración alternativa de text durante estas pruebas, para poder reiniciar y probar la nueva configuración, pero de la misma manera mantener la configuración estable antigua.

Durante el proceso de arranque, además del initramfs necesario para el arranque inicial, se producirá también la carga del resto de módulos por detección automática. Si no se carga algún módulo deseado siempre puede forzarse su carga al incluir su nombre implícitamente en el fichero de configuración /etc/modules.

También puede darse o desearse el caso contrario: evitar la carga de un módulo que puede detectarse erróneamente o para el que existe más de una alternativa posible. En este caso se utilizan técnicas de listas negras de módulos (típicamente la lista negra se guarda en /etc/modprobe.d/blacklist.conf).


6. Virtualización en el núcleo

Una de las áreas en expansión, en la administración de IT, es la virtualización de sistemas. GNU/Linux ha ido con el tiempo incorporando diferentes posibilidades provenientes tanto de soluciones comerciales, como de diferentes proyectos de código abierto.

La virtualización de sistemas es un recurso básico actual en las empresas y organizaciones para mejorar su administración de sistemas, disminuir costes y aprovechar los recursos de hardware de manera más eficiente.

En general, en el pasado si necesitábamos varias instancias de uno (o más) sistemas operativos, teníamos que adquirir un servidor para cada instancia a implantar. La corriente actual es comprar servidores mucho más potentes y utilizar virtualización en estos servidores para implantar los diferentes sistemas en desarrollo o producción.

Normalmente, en virtualización disponemos de un sistema operativo instalado (que habitualmente se denomina sistema host) y una serie de máquinas virtuales sobre este sistema (denominados sistemas guest). Aunque también hay soluciones que sustituyen al sistema operativo host por una capa denominada hypervisor.

La virtualización como solución nos permite optimizar el uso de nuestros servidores o bien, por ejemplo en el caso de escritorio, disponer de máquinas de test de otros sistemas operativos conviviendo en la misma máquina simultáneamente. En el caso de GNU/Linux disponemos de múltiples soluciones que permiten tanto un caso como el otro. También podemos disponer tanto de GNU/Linux como sistema host que aloja máquinas virtuales, como utilizarlo como máquina virtual sobre otro sistema diferente o bien sobre otro sistema host también GNU/Linux. Un esquema, este último, particularmente útil en el caso de administración porque nos permitirá, por ejemplo, examinar y ejecutar diferentes distribuciones GNU/Linux sobre un mismo sistema host base.

Existen muchas soluciones de virtualización, pero por mencionar algunas de las más populares en sistemas GNU/Linux, disponemos (ordenamos de más a menos en relación directa con el núcleo):

KVM
Xen
OpenVZ
VirtualBox
VMware


7. Futuro del núcleo y alternativas

Los avances en el núcleo de Linux en determinados momentos fueron muy rápidos, pero actualmente, ya con una situación bastante estable con los núcleos de la rama 2.6.x, cada vez pasa más tiempo entre las versiones que van apareciendo. En cierta manera esto es bastante positivo: permite tener tiempo para corregir errores cometidos, ver aquellas ideas que no funcionaron bien y probar nuevas ideas, que, si resultan, se incluyen.

Comentaremos en este apartado algunas de las ideas de los últimos núcleos y algunas que están previstas, para dar indicaciones de lo que será el futuro próximo en el desarrollo del núcleo.
En la antigua rama 2.4.x del núcleo se realizaron algunas aportaciones en:

Cumplimiento de los estándares IEEE POSIX, lo que permite que muchos de los programas existentes de UNIX pueden recompilarse y ejecutarse en Linux.
Mejor soporte de dispositivos: PnP, USB, puerto paralelo, SCSI, etc.
Soporte para nuevos sistemas de ficheros, como UDF (CD-ROM reescribibles como un disco). Otros sistemas con journal, como los Reiser de IBM o el ext3, que permiten tener un registro (journal) de las modificaciones de los sistemas de ficheros, y así poder recuperarse de errores o tratamientos incorrectos de los ficheros.
Soporte de memoria hasta 4 GB. En su día surgieron algunos problemas (con núcleos 1.2.x) que no soportaban más de 128 MB de memoria (una cantidad que en aquel tiempo era mucha memoria).
Se mejoró la interfaz /proc. Se trata de un pseudosistema de ficheros (el directorio /proc) que no existe realmente en disco, sino que es simplemente una forma de acceder a datos del núcleo y del hardware de una manera organizada.
Soporte del sonido en el núcleo: se añadieron parcialmente los controladores Alsa que antes se configuraban por separado.
Se incluyó soporte preliminar para el RAID software y el gestor de volúmenes dinámicos LVM1.

En la serie actual, la rama del núcleo 2.6.x, se dispuso de importantes avances respecto a la anterior (con las diferentes revisiones .x de la rama 2.6):

Mejores prestaciones en SMP, importante para sistemas multiprocesadores muy utilizados en entornos empresariales y científicos.
Mejoras en el planificador de CPU (scheduler). En particular, se introducen avances para mejorar el uso de tareas interactivas de usuario, imprescindibles para mejorar el uso de Linux en un ambiente de escritorio.
Mejoras en el soporte multithread para las aplicaciones de usuario. Se incorporan nuevos modelos de hilos NGPT (IBM) y NPTL (Red Hat) (con el tiempo se consolidó finalmente la NPTL).
Soporte para USB 2.0 y, posteriormente, para USB 3.0.
Controladores Alsa de sonido incorporados en el núcleo.
Nuevas arquitecturas de CPU de 64 bits, se soportan AMD x86_64 (también conocida como amd64) y PowerPC 64 y IA64 (arquitectura de los Intel Itanium).
Sistemas de ficheros con journal: JFS, JFS2 (IBM) y XFS (Silicon Graphics).
Mejoras con journal en los sistemas de ficheros propios, ext3 y ext4, con mejoras del tamaño máximo de los archivos y de rendimiento general.
Mejoras de prestaciones en E/S y nuevos modelos de controladores unificados.
Mejoras en implementación de TCP/IP y el sistema NFSv4 (compartición de sistema de ficheros por red con otros sistemas).
Mejoras significativas para núcleo apropiativo: permite que internamente el núcleo gestione varias tareas que se pueden interrumpir entre ellas, imprescindible para implementar eficazmente sistemas de tiempo real y también para aumentar el rendimiento de tareas interactivas.
Suspensión del sistema y restauración después de reiniciar (por núcleo).
UML, User Mode Linux, una especie de máquina virtual de Linux sobre Linux que permite ver un Linux (en modo usuario) ejecutándose sobre una máquina virtual. Esto es ideal para la propia depuración, ya que se puede desarrollar y probar una versión de Linux sobre otro sistema, y es útil tanto para el propio desarrollo del núcleo como para un análisis de seguridad del mismo. En versiones posteriores este concepto evolucionó hacia el módulo KVM.
Técnicas de virtualización incluidas en el núcleo: en las distribuciones se han ido incorporando diferentes técnicas de virtualización, que necesitan extensiones en el núcleo. Cabe destacar, por ejemplo, núcleos modificados para Xen, Virtual Server (Vserver), OpenVZ o el propio módulo KVM.
Nueva versión del soporte de volúmenes LVM2.
Nuevo pseudosistema de ficheros /sys, destinado a incluir la información del sistema, y dispositivos que se irán migrando desde el sistema /proc, dejando este último con información relacionada con los procesos y su desarrollo en ejecución, así como la información dinámica del propio núcleo.
Módulo FUSE para implementar sistemas de ficheros en espacio de usuario (en especial usado para el caso de NTFS).

Para conocer los cambios de las versiones más recientes de Linux, pueden examinarse los ficheros ChangeLog que acompañan a cada versión del núcleo, o consultar un registro histórico que se mantiene en Kernelnewbies.org, en especial http://kernelnewbies.org/ LinuxChanges, que mantiene los cambios de la última versión y pueden consultarse los del resto de versiones (misma dirección con /Linux26Changes).

En el futuro se tiene pensado mejorar los aspectos siguientes:

Incremento de la tecnología de virtualización en el núcleo, para soportar diferentes configuraciones de sistemas operativos y diferentes tecnologías de virtualización, así como un mejor soporte del hardware para virtualización incluido en los procesadores que surjan en las nuevas arquitecturas. Están bastante soportadas x86 y x86_64, con KVM, por ejemplo, pero otras no lo están o solamente parcialmente.
El soporte de SMP (máquinas multiprocesador), de CPU de 64 bits (Xeon, nuevos multicore de Intel y Opteron de AMD), el soporte de CPU multicore y la escalabilidad de aplicaciones multihilo en estas CPU.
La mejora de sistemas de ficheros para clusterización y grandes sistemas distribuidos.
Por el contrario, la mejora en núcleos más optimizados para dispositivos móviles (PDA, smartphones, tablets, etc.).
Mejora en el cumplimiento de los estándar POSIX.
Mejora de la planificación de la CPU. Aunque en la serie inicial de la rama 2.6.x se hicieron muchos avances en este aspecto, todavía hay un bajo rendimiento en algunas situaciones. En particular en el uso de aplicaciones interactivas de escritorio se están estudiando diferentes alternativas, para mejorar este y otros aspectos relacionas con el escritorio y el uso del rendimiento gráfico.