wandres.dev
PARÁMETROS Y /SYS · module_param, sysfs, debugfs

Exponer datos: procfs, sysfs y debugfs

El kernel comunica con el usuario a través de archivos virtuales. /proc, /sys y debugfs son tres formas de exponer y controlar tu módulo desde el espacio de usuario.

⏱ 12 min

En Unix, todo es un archivo — y el kernel lleva esa filosofía a su interior. En vez de inventar APIs raras, expone su estado y sus controles como archivos virtuales que lees y escribes con cat y echo. Aprender a crear esos archivos es dar a tu módulo una interfaz limpia.

🎯 Al terminar esta lección sabrás
  • Los tres sistemas de archivos virtuales.
  • procfs: el veterano.
  • sysfs: estructurado, un valor por archivo.
  • debugfs: para depuración, sin reglas.

Tres ventanas al kernel

📜

procfs (/proc)

El histórico. Nació para info de procesos y creció para todo. Flexible pero desordenado; hoy se prefiere no añadirle cosas nuevas.

🗂️

sysfs (/sys)

Estructurado y disciplinado: un valor por archivo, jerarquía que refleja el device model. La forma moderna de exponer atributos.

🐞

debugfs (/sys/kernel/debug)

Para depuración. Sin las reglas estrictas de sysfs: expón lo que necesites para diagnosticar, sin compromiso de estabilidad.

sysfs: la regla de “un valor por archivo”

sysfs impone una disciplina: cada archivo expone un valor legible/escribible. Se construye sobre kobject y atributos:

// un atributo de solo lectura que expone un contador
static ssize_t contador_show(struct kobject *kobj,
                             struct kobj_attribute *attr, char *buf) {
    return sysfs_emit(buf, "%d\n", mi_contador);
}
static struct kobj_attribute contador_attr = __ATTR_RO(contador);
// … registrar con sysfs_create_file bajo un kobject …
cat /sys/kernel/mimodulo/contador     # lee "42"
Interfaces de archivo: la elegancia de Unix por dentro

Detente en la profundidad de esta idea. El kernel podría exponer su estado con syscalls a medida, ioctls crípticos o APIs binarias. En cambio, elige archivos: quieres el número de un contador, cat un archivo; quieres cambiar un ajuste, echo en otro. Cualquier lenguaje, cualquier script, cualquier herramienta que sepa leer y escribir archivos puede hablar con el kernel — sin bindings, sin librerías. Un script de shell puede monitorizar y controlar el kernel. Esta uniformidad (“todo es un archivo”) no es nostalgia: es una decisión de diseño que multiplica la componibilidad de todo el sistema. Cuando diseñes la interfaz de tu módulo, piensa en archivos: ¿qué valores expondrías para leer? ¿qué controles para escribir? Una buena interfaz de sysfs hace tu driver observable y controlable con las herramientas más simples que existen.

debugfs: para desarrollar

Mientras desarrollas, debugfs es tu amigo: crea archivos de diagnóstico sin las garantías de estabilidad de sysfs (sysfs es ABI: una vez publicado, no puedes romperlo; nivel 21 de C23). Perfecto para volcar estadísticas internas, contadores, estado — cosas que ayudan a depurar pero que no forman parte de la interfaz oficial.

struct dentry *dir = debugfs_create_dir("mimodulo", NULL);
debugfs_create_u32("errores", 0444, dir, &contador_errores);
💡
Elige la ventana correcta

La guía práctica: sysfs para atributos estables que los usuarios y herramientas usarán (es ABI, cuídalo); debugfs para diagnóstico interno mientras desarrollas o para info que puede cambiar; procfs, evítalo para cosas nuevas (es legado, aunque lo verás mucho en código existente). Y para operaciones más ricas que “leer/escribir un valor”, los char devices con sus file_operations (nivel 13) son la herramienta.

⚔️ Dale una interfaz a tu módulo
  1. Explora /proc, /sys y /sys/kernel/debug en tu sistema: mira qué expone el kernel como archivos.
  2. Añade a tu módulo un atributo sysfs de solo lectura que exponga un contador.
  3. Léelo con cat desde userspace.
  4. Crea un archivo debugfs con debugfs_create_u32 para una estadística interna.