wandres.dev
ESTILO Y CALIDAD · coding style, checkpatch

checkpatch y las herramientas de revisión

Antes de que un humano vea tu código, hazlo pasar por las herramientas: checkpatch.pl para el estilo, sparse y smatch para bugs. Automatiza la calidad que el kernel exige.

⏱ 10 min

El kernel tiene estándares altísimos y un proceso de revisión exigente. La buena noticia: mucha de esa exigencia está automatizada. Antes de que un mantenedor gaste su tiempo en tu parche, pásalo por las herramientas — encontrarán los problemas de estilo y muchos bugs por ti.

🎯 Al terminar esta lección sabrás
  • checkpatch.pl: el verificador de estilo.
  • sparse: el analizador semántico del kernel.
  • smatch y Coccinelle.
  • Integrarlo en tu flujo.

checkpatch.pl

El kernel trae un script que verifica que tu código (o tu parche) cumple el estilo y detecta errores comunes:

# sobre un archivo
scripts/checkpatch.pl --file drivers/midriver/midriver.c

# sobre un parche (lo normal antes de enviarlo)
scripts/checkpatch.pl mi-parche.patch

Reporta errores (que debes arreglar) y avisos (que casi siempre debes arreglar): tabs mal, líneas largas, llaves, espacios, y patrones peligrosos. Pasar checkpatch limpio es el mínimo antes de enviar un parche; los mantenedores rechazan de plano lo que no lo cumple.

sparse: el analizador del kernel

sparse es un analizador estático hecho para el kernel. Entiende anotaciones especiales del kernel (__user, __iomem, __rcu) que marcan la naturaleza de los punteros, y detecta errores que el compilador normal no ve:

make C=1 drivers/midriver/      # compila con sparse activado
⚡
Las anotaciones que hacen visible lo invisible

Aquí hay una lección profunda de ingeniería. Un char * de userspace y un char * de kernelspace son, para C, el mismo tipo — pero mezclarlos es un bug de seguridad grave (nivel 12). El kernel resuelve esto con anotaciones: marca los punteros de usuario como __user, la memoria de dispositivos como __iomem, los datos protegidos por RCU como __rcu. El compilador las ignora, pero sparse las comprueba: si desreferencias un puntero __user directamente, o pasas memoria de kernel donde se espera de usuario, sparse lo caza. Es hacer visible al análisis una distinción que el sistema de tipos de C no captura por sí solo. Correr sparse (make C=1) sobre tu código atrapa una clase entera de bugs de la frontera usuario/kernel antes de que existan. Es la respuesta del kernel a las limitaciones de tipado de C, y una razón por la que su código, pese a estar en C, es tan robusto.

smatch y Coccinelle

🔎

smatch

Analizador estático más profundo que sparse: sigue el flujo del código y encuentra fugas, dereferencias nulas condicionales, y errores lógicos.

🔧

Coccinelle

Busca y transforma patrones en el código a gran escala (parches semánticos). Se usa para arreglos masivos coherentes en todo el kernel.

💡
Automatiza antes de pedir revisión humana

La regla de oro del contribuidor: nunca hagas perder el tiempo a un revisor con algo que una herramienta habría cazado. Antes de enviar un parche, pásalo por checkpatch (estilo), compila con sparse (make C=1) y, si puedes, smatch. Arregla todo lo que reporten. Esto respeta el tiempo de los mantenedores (voluntarios y muy ocupados), aumenta tus probabilidades de que acepten tu parche, y te enseña los estándares por repetición. La calidad automatizada es la cortesía básica del proceso del kernel (nivel 30).

⚔️ Verifica tu código
  1. Pasa scripts/checkpatch.pl --file sobre tu módulo y arregla lo que reporte.
  2. Compila con make C=1 (sparse) y observa si detecta algo.
  3. Investiga las anotaciones __user, __iomem, __rcu en el código del kernel.
  4. Deja tu módulo pasando checkpatch y sparse limpios.