Inauguramos la sección dedicada a la depuración del kernel con un estudio de la técnica más simple e intuitiva:
trazas con printk.
El uso de trazas es la tendencia natural, por su sencillez, cuando se trata de depurar software en el ámbito del espacio de usuario. En este artículo veremos cómo también es posible realizar esta práctica en el espacio kernel.

El editor de texto VIM nos facilita la tarea de manejar los fuentes del kernel Linux de una manera simple y potente. En este pequeño tutorial, presentamos algunas de las características del editor VIM, que lo convierten en todo un IDE para hackear el kernel Linux sin dificultades.

Las listas son tipos de datos abstractos de amplio uso en computación. El kernel Linux hace uso intensivo de estas estructuras en la representación y manipulación de sus datos. Los desarrolladores del kernel, han definido una implementación de este tipo de datos abstracto, para unificar criterios y evitar así que cada programador reinvente la rueda. En este artículo vamos a estudiar, por tanto, la implementación estándar del kernel Linux del tipo lista.

En esta ocasión vamos a enfrentarnos al reto de crear un nuevo planificador de disco, o planificador de e/s. Ya hemos visto que existe un nutrido grupo de planificadores posibles a partir de la serie 2.6 del kernel:

• Anticipatory - AS (Jens Axboe y Nick Piggin)
• Complete Fairness Queuing - CFQ (Jens Axboe)
• Deadline (Jens Axboe)
• No Operation - NOOP (Jens Axboe)

Nuestra intención es adentrarnos en la codificación real del kernel Linux, extendiendo sus funcionalidades, no pretendemos proporcionar un nuevo planificador que supere o mejore los anteriores.

Hemos creado una interesante sección, en la que presentamos enlaces a las páginas personales de algunos de los kernel hackers más conocidos: Kernel hackers. Visitar estos sitios con frecuencia, puede ser una buena práctica para satisfacer nuestra curiosidad y mantenernos al día con las últimas novedades en el desarrollo del kernel. Ellos son parte de los motores de esta elitista comunidad.

Continuamos con el estudio de la Block I/O Layer. Para ello abordaremos el tema desde otra perspectiva: la creación de un driver de bloques. En el siguiente artículo crearemos un sencillo driver de disco (en RAM) con el cual nos acercaremos al API que nos proporciona el kernel para dicha empresa. Como veremos, conceptos que no quedaron claros en el estudio de la capa de entrada/salida de bloques, se afianzan con esta aproximación práctica.

Este artículo, es el segundo de una serie de tres, cuyo fin es la creación de un taller práctico en el que intentaremos crear un nuevo planificador de entrada/salida (I/O scheduler).

En la nueva sección Bibliografía podemos encontrar una buena lista de libros dedicados al estudio del kernel Linux, también encontraremos menciones a libros de apoyo a las distintas materias, como libros de hardware, técnicas de programación, teoría general de sistemas operativos, etc.

Uno de los objetivos principales del diseño del kernel 2.6 fue la modificación del sistema de entrada/salida de bloques. En este documento realizaremos un estudio teórico de la capa del kernel Linux encargada de manejar los dispositivos de bloques (discos duros, CDROM, ...), conocida con el nombre “Block I/O Layer”.

Con la llegada de la serie 2.6 del kernel, el modelo de desarrollo ha sufrido importantes cambios. Estos cambios no han sido evidentes y por el contrario sí han sido fuente de controversia.

Recientemente en la lista de desarrollo del kernel (LKML) se ha intentado documentar dicho modelo, para plasmar sus puntos fundamentales. Prueba de ello es el presente documento elaborado por un integrante de la lista, Paolo Ciarrocchi, que hemos traducido del documento original: "Introduction to linux kernel development process".