Git para entender el kernel · Kernel de Linux

Git nació para el kernel (Linus lo escribió para gestionarlo). Por eso el historial del kernel es una mina de oro: cada línea tiene una historia, cada decisión un mensaje de commit que la explica. Aprender a leer ese historial es una habilidad de kernel tan importante como leer el código.

🎯 Al terminar esta lección sabrás

git blame: quién y por qué escribió una línea.
git log: la historia de un archivo o función.
git bisect: encontrar el commit que rompió algo.
Los árboles de subsistemas.

git blame: la historia de cada línea

git blame kernel/sched/core.c    # cada línea, con su commit y autor
git blame -L 100,120 mm/slab.c   # solo un rango

blame te dice qué commit introdujo cada línea. Con el hash, git show <hash> te da el mensaje completo — que en el kernel suele explicar por qué se hizo el cambio, qué problema resolvía, qué alternativas se descartaron.

⚡

En el kernel, el 'porqué' vive en git

El código te dice qué hace; casi nunca por qué. Y en el kernel, el “por qué” importa muchísimo: hay líneas que parecen absurdas hasta que descubres que arreglan un bug en un hardware concreto de 2009, o que evitan una condición de carrera sutil. Esa razón vive en el mensaje de commit. Los mensajes del kernel son famosamente detallados —es un requisito del proceso (nivel 30)— y forman la mejor documentación de diseño que existe. Antes de tocar o cuestionar un código que no entiendes, haz git blame y lee el commit que lo introdujo. Nueve de cada diez veces, la razón está ahí, escrita por quien lo vivió. Leer el historial del kernel es asistir a tres décadas de decisiones de ingeniería de sistemas de élite.

git log: la evolución

git log --oneline mm/slab.c          # historia resumida de un archivo
git log -p kernel/sched/fair.c        # con los diffs completos
git log --grep="race condition"       # commits que mencionan algo
git log -S "container_of" -- fs/       # commits que añadieron/quitaron ese texto

git log -S (“pickaxe”) es potentísimo: encuentra cuándo apareció o desapareció un fragmento de código concreto en toda la historia.

git bisect: cazar regresiones

Si algo funcionaba y ahora no, bisect encuentra el commit culpable con una búsqueda binaria automática:

git bisect start
git bisect bad                 # la versión actual falla
git bisect good v7.0           # esta versión funcionaba
# git te va dando commits intermedios; compilas, pruebas, y marcas:
git bisect good   # o  git bisect bad
# … repite ~log2(N) veces hasta que git señala el commit exacto …
git bisect reset

💡

bisect convierte 'algo lo rompió' en un commit exacto

Entre dos versiones puede haber decenas de miles de commits. git bisect encuentra el culpable en ~15 pasos (búsqueda binaria) en vez de revisarlos uno a uno. Es la herramienta estándar para reportar y arreglar regresiones del kernel: “esto funcionaba en 7.0 y falla en 7.1” se convierte, con bisect, en “el commit abc123 lo rompió”. Los mantenedores lo esperan en cualquier reporte de regresión serio.

Los árboles de subsistemas

El kernel no se desarrolla en un solo repositorio lineal: cada subsistema tiene su árbol mantenido por su maintainer (el árbol de red, el de mm, el de un driver…), y se integran en el árbol de Linus por ventanas de merge. El archivo MAINTAINERS te dice quién mantiene qué y a qué árbol/lista enviar los parches. Es la primera parada antes de contribuir (nivel 30).

⚔️ Investiga con git

Haz git blame sobre una función del kernel y lee el commit que introdujo una línea que te intrigue.
Usa git log --grep para encontrar commits sobre un tema (p. ej. “memory leak”).
Prueba git log -S "alguna_funcion" para ver cuándo apareció.
Abre el archivo MAINTAINERS y localiza quién mantiene un subsistema que te interese.