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.
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.
- 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"
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);
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.
- Explora
/proc,/sysy/sys/kernel/debugen tu sistema: mira qué expone el kernel como archivos. - Añade a tu módulo un atributo sysfs de solo lectura que exponga un contador.
- Léelo con
catdesde userspace. - Crea un archivo debugfs con
debugfs_create_u32para una estadística interna.