PDF de programación - Hackeando el Kernel

Hackeando el Kernel • P O RTA DA

Qué hacer con el núcleo de Linux

HACKEANDO EL
KERNEL

su nivel de competencia. Debido a este enfo-
que, los antiguos proyectos de software libre
como libc tenían que adaptarse o correr el
riesgo de ser bifurcados y entrar en competen-
cia con proyectos que estarían mejor realiza-
dos y con una mayor base de desarrolladores.
En última instancia, Linus, como líder del
proyecto, tiene la última palabra sobre las con-
tribuciones del núcleo y el proceso de
desarrollo en sí. Pero al igual que todos los
proyectos de código abierto, está sujeto a la
voluntad de los otros desarrolladores para

El núcleo de Linux es el verdadero

Linux. Este mes nos centramos en

las

herramientas

para

la

configuración y adaptación del

núcleo. POR ZACK BROWN

El núcleo es el cerebro en el centro de

nuestros sistemas Linux. En esta
entrega examinamos algunas técnicas
para gestionar y personalizar el núcleo Linux.
Comenzaremos con un exhaustivo artículo
del creador de Knoppix – y columnista de
Linux Magazine, Klaus Knopper – sobre la
compilación, actualización y personalización
del núcleo. El experto en sonido Linux, Dave
Phillips, sopesa cómo afinar el núcleo para las
aplicaciones multimedia, y el artículo final
estudia algunas herramientas populares de

optimización de Linux. Si estás preparado
para avanzar en el juego de la configuración
del núcleo, pasa a leer algunos hacks prácticos
del núcleo. Pero primero le pediremos al autor
de Noticias del Kernel, Zack Brown, que nos
ponga en antecedentes sobre cómo llegó el
código del núcleo a nuestro disco duro.

Proceso de Desarrollo

El proceso de desarrollo del núcleo de Linux es
un sistema fascinante que está en constante
revisión. Antes de Linux, a pesar de las licen-
cias de software libre existentes, los proyectos
usaron un enfoque de desarrollo muy estricto
que los mantuvieron en una torre de marfil,
haciendo caso omiso de las contribuciones de
los demás sobre la base de que sólo los exper-
tos en la materia podrían comprender sufi-
cientemente bien los problemas de la codifica-
ción como para producir un buen resultado.
La propuesta de Linus Torvalds era justo lo
contrario, planteando la descabellada hipóte-
sis de que las contribuciones válidas podían
llegar de cualquier persona, casi sin importar

EN PORTADA

Trabajando con el Kernel . . . . . . . . . . .19

Herramientas . . . . . . . . . . . . . . . . . . . .28

Multimedia y el Kernel . . . . . . . . . . . . .34

W W W . L I N U X - M A G A Z I N E . E S

Número 49

17

P O RTA DA • Hackeando el Kernel

seguir adelante con sus decisiones. El
desarrollo del núcleo, igual que cualquier pro-
yecto de software libre, puede ser controver-
tido, pudiendo estallar grandes cismas entre
desarrolladores con diferentes ideas acerca de
cómo hacer las cosas. Algunos proyectos de
código abierto pueden volverse tan divisibles
que un desarrollador bifurque todo el código
base y continúe el desarrollo con cualquier
otro colaborador que se moleste en seguirlo.

¿Cómo se desarrolla el núcleo hoy día? Para
empezar, la comunidad de desarrollo apoya
varias listas de correo, la primera de las cuales
es linuxkernel, que puedes leer en http://
www.tux.org/lkml. Cada lanzamiento del
núcleo también incluye un archivo MAINTAI-
NERS en el directorio de documentación, el
cual lista cada uno de los responsables oficia-
les de cada porción del núcleo, junto con las
listas de correo que corresponden a ese trozo.
Cada lista de correo es (o debería ser) un lugar
donde puedes enviar mensajes sin que tengas
que suscribirte. Los que contesten te incluirán
en el CC en sus respuestas. Este acuerdo es
parte de la idea original de fomentar las contri-
buciones de todos. No tienes que estar profun-
damente involucrado en el desarrollo del
núcleo o de cualquier área particular de
desarrollo del núcleo para hacer una contribu-
ción. Lo único que necesitas es el código
fuente y el deseo de ayudar.

Las listas de correo son el principal medio
de comunicación entre los desarrolladores del
kernel. Los programadores hacen propuestas,
presentan y discuten los parches, debaten de
controversias y anuncian los nuevos lanza-
mientos de varios proyectos, incluido el propio
núcleo. Pero el archivo MAINTAINERS es sólo
el comienzo del proceso. Los desarrolladores
mantienen varias bifurcaciones del núcleo,
cada una diseñada con el objetivo último de
revertir sus diferencias al núcleo principal.
Con la reciente llegada del sistema de gestión
de código Git (desarrollado por Linus y una
serie de desarrolladores del núcleo), ahora es
posible que los grupos de desarrolladores
desarrollen sus propias bifurcaciones comu-
nes antes de revertir los cambios ascendentes
a Linus.

Firmar

En función de la parte del núcleo en la que
estés trabajando y del mantenedor con el que
hayas contactado, el mantenedor firmará tu
parche y lo incluirá en alguno de los árboles
públicos. Una vez allí, el parche será revisado
por una amplia audiencia. La primera vez que
envíes uno, las únicas personas que realmente
lo probarán serán aquellas que se tomen la

molestia de aplicarlo manualmente en sus
árboles del núcleo. Aunque una vez en el
árbol público, el parche se prueba al menos
marginalmente por cualquier persona que
descargue e intente probar ese árbol. Algunos
árboles son más populares que otros. El árbol
-mm de Andrew Morton es en la actualidad el
núcleo de elección para varios desarrollado-
res, los cuales lo hacen funcionar con regulari-
dad en sus sistemas domésticos.

Hace varios años, la comunidad desarrolló
el concepto de los lugartenientes del núcleo,
un círculo de desarrolladores experimentados
en los que Linus confía para enviar solamente
buenos y sólidos parches. La idea de un lugar-
teniente es más una idea útil que cualquier
acuerdo de tipo formal. Algunas personas que
constantemente hacen un buen trabajo tien-
den a estar capacitadas para obtener sus
envíos más rápidamente y tienden a ser las
que Linus prefiere entre las distintas rutas de
mantenedores a través de ciertos parches.
Básicamente, la relación social entre Linus y
los lugartenientes reduce aún más el cuello de
botella de Linus de tener que revisar cada par-
che. Aunque estos lugartenientes son una
parte legítima del proceso de desarrollo del
kernel, las pocas veces que alguien ha
enviado un mensaje a la lista de correo para
pedir una lista de los lugartenientes de Linus,
la solicitud no se ha tomado demasiado en
serio, ya que no existe una designación for-
mal. Es sólo un pequeño grupo de personas
que parecen trabajar bien con los parches.

Mantenedores

Si tu parche hace algo más que solucionar un
error – por ejemplo, es un nuevo controlador
o alguna otra discreta parte del núcleo – tam-

lo han hecho y quieres mantener el pro-
yecto en su sitio, lo mejor que se puede
hacer es preguntarle o preguntar en la lista
de correo. Probablemente alguien con auto-
ridad sobre esa parte del núcleo se pondrá
en contacto contigo. En algunos casos, el
mantenimiento se entrega directamente a
través de anuncio público después de que el
mantenedor actual ha terminado de realizar
una búsqueda en privado. La obligación del
mantenedor es bastante fluida. Un desarro-
llador puede hacer la mayor parte de la
codificación personalmente o simplemente
actuar como un guardián del código, sobre
todo al aceptar los parches de otras perso-
nas. Casi el único requisito es que un desa-
rrollador debe mantener siempre su entrada
en el archivo MAINTAINERS al día y res-
ponder a los mensajes de correo electró-
nico, aunque sea para decir que ya no tra-
baja más en el proyecto y que le gustaría
encontrar un sustituto.

Conclusión

El proceso de desarrollo del núcleo tiene su
propia cultura y su propio sentido de la eti-
queta. Es una cultura que favorece la con-
fianza en los otros, y que recompensa a las
personas que contribuyen y las que aceptan
comentarios sobre sus contribu-
ciones. A medida que el pro-
ceso sigue evolucionando,
hay una cuestión pendiente:
¿Cómo puede el proyecto
hacer el mejor uso posible
de la voluntad de ayudar de
todos? I

bién deberías considerar la posibilidad de pre-
sentar un parche para el archivo MAINTAI-
NERS incluyéndote como mantenedor oficial.
Nadie tiene la tarea oficial de identificar man-
tenedores y añadirlos a la lista, corresponde a
los propios contribuidores asumir la responsa-
bilidad de su parte del código. En algunos
casos, la tarea de mantenimiento es evidente.
Si has escrito un controlador y planeas mante-
nerlo, adelante, inscríbete en la lista como
mantenedor. Si alguien ha abandonado el
mantenimiento de algo, o si sospechas que

18

Número 49

W W W . L I N U X - M A G A Z I N E . E S