wandres.dev
CONFIGURAR (KCONFIG) · menuconfig, y/m/n

Escribir tu propia entrada Kconfig

El lenguaje Kconfig por dentro: cómo se declara una opción, los tipos bool y tristate, las dependencias (depends on, select) y cómo tu feature aparece en menuconfig.

⏱ 11 min

Cuando añades una feature al kernel —tu driver, tu subsistema— necesita una entrada Kconfig para que se pueda activar o desactivar. Aprender el lenguaje Kconfig es lo que integra tu código en el sistema de configuración, en vez de dejarlo como un parche suelto.

🎯 Al terminar esta lección sabrás
  • La sintaxis de una entrada Kconfig.
  • Tipos: bool vs tristate.
  • Dependencias: depends on y select.
  • Cómo aparece en menuconfig.

Una entrada Kconfig

Cada directorio del kernel con features tiene un archivo Kconfig. Una entrada define una opción de configuración:

config MI_DRIVER
	tristate "Soporte para mi dispositivo"
	depends on PCI
	default n
	help
	  Este driver da soporte a mi dispositivo.
	  Compílalo como módulo (M) si no estás seguro.

Esto crea la opción CONFIG_MI_DRIVER, que aparece en menuconfig con el texto entre comillas, solo si se cumple depends on PCI, y cuya ayuda es el bloque help.

bool vs tristate

🔘

bool

Dos estados: dentro del kernel (y) o fuera (n). Para features que no tienen sentido como módulo (opciones del núcleo, del arranque).

🔀

tristate

Tres estados: dentro (y), módulo (m) o fuera (n). Para todo lo que pueda ser un módulo cargable — la mayoría de drivers.

La regla: si tu código puede ser un módulo (casi todos los drivers), usa tristate para dar esa flexibilidad (recuerda el nivel 4.1: la opción m es oro).

Dependencias: depends on y select

config MI_DRIVER
	tristate "Mi driver"
	depends on PCI && NET       # solo disponible si PCI y NET están activos
	select CRC32                # activa CRC32 automáticamente (lo necesito)
⚡
depends on vs select: la diferencia que confunde a todos

Dos formas de expresar “necesito otra cosa”, con filosofías opuestas. depends on X dice “solo muéstrame esta opción si X ya está activo” — respeta la elección del usuario; si X está apagado, tu opción ni aparece. select X dice “activa X automáticamente porque lo necesito” — fuerza a X sin preguntar. La regla de oro de los mantenedores: usa depends on para dependencias visibles que el usuario podría querer controlar, y reserva select solo para dependencias “invisibles” de infraestructura (como una librería interna que el usuario no configuraría a mano). Abusar de select crea dependencias circulares y estados de configuración imposibles — es uno de los errores por los que más se rechazan parches. Piensa: “¿el usuario debería poder decidir esto?”. Si sí, depends on; si es plumbing interno, select.

Cómo se conecta al build

Para que Kconfig encuentre tu entrada, el Kconfig del directorio padre debe incluir el tuyo con source, y tu opción CONFIG_MI_DRIVER gobierna la compilación en el Makefile (nivel 5.2):

obj-$(CONFIG_MI_DRIVER) += midriver.o

obj-$(CONFIG_MI_DRIVER) se expande a obj-y (si es y), obj-m (si es m) o nada (si es n). Así una sola línea conecta tu opción de Kconfig con qué y cómo se compila. Esta es la elegancia del sistema: la configuración fluye del .config al Makefile automáticamente.

⚔️ Integra una feature
  1. Abre un Kconfig de drivers/ y estudia varias entradas reales (tipos, depends, help).
  2. Escribe una entrada tristate con depends on para un driver imaginario.
  3. Explica cuándo usarías select en vez de depends on.
  4. Escribe la línea obj-$(CONFIG_...) correspondiente en un Makefile.