Instalación y compilación/carga manual de módulos de kernel para drivers de red/vídeo

Objetivo:

Comprender el flujo avanzado de compilación e instalación manual de módulos externos o personalizados para el kernel de Linux (como controladores de red o vídeo), gestionando dependencias, carga en caliente y resolución de conflictos mediante las herramientas nativas lsmod y modprobe.

Escenario:

  • Herramientas: Terminal Linux, comandos lsmod, modprobe, modinfo, depmod, herramientas de compilación (make, gcc, cabeceras del kernel).
  • Conceptos analizados: Árbol de directorios de módulos en /lib/modules/, ficheros de código objeto con extensión .ko, dependencias de símbolos del kernel y compilación fuera del árbol (out-of-tree).
  • Proceso clave: Simulación de la compilación de un módulo de controlador externo, generación de la base de datos de dependencias con depmod y carga controlada en el kernel en ejecución.

Escenario Real: Soporte para hardware de última generación o propietario

Una nueva tarjeta adaptadora de red o un controlador de vídeo especializado incorpora un chipset muy reciente cuyo driver oficial no viene incluido por defecto en la versión estándar del kernel de la distribución. Como administrador de sistemas avanzado, debes compilar el código fuente del controlador de forma manual, generar el módulo objeto e insertarlo de forma segura en el núcleo del sistema operativo sin interrumpir la operatividad del servidor.

Por defecto, las distribuciones de Linux incluyen miles de drivers genéricos, pero componentes de hardware específicos de red o tarjetas gráficas avanzadas exigen compilar módulos a medida. Dominar el proceso de compilación manual y la inyección mediante modprobe es una habilidad clave en entornos de alta especialización técnica.

NOTA: Para realizar esta práctica de forma segura, utilizaremos código fuente de drivers simulados de pruebas o módulos de ejemplo estándar compatibles con tu arquitectura, evitando corromper controladores gráficos reales en servidores de producción.

Instrucciones:

Fase 1: Preparación del entorno de compilación y cabeceras del kernel:

  • Instalar las herramientas de desarrollo y las cabeceras (headers) correspondientes a la versión exacta del kernel actual: sudo apt update && sudo apt install -y build-essential linux-headers-$(uname -r)
  • Comprobar que el directorio de cabeceras del kernel en uso existe correctamente en el sistema: ls -l /lib/modules/$(uname -r)/build

Fase 2: Obtención o diseño del código fuente del módulo y Makefile:

  • Crear un directorio de trabajo para la compilación manual: mkdir -p ~/driver_custom && cd ~/driver_custom
  • Crear un fichero de automatización de compilación llamado Makefile utilizando un editor de textos: nano Makefile
  • Añadir la estructura estándar recomendada por el kernel para compilar un módulo externo (ejemplo con un módulo simulado llamado mi_driver_red): 
    obj-m += mi_driver_red.o

all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
  • Guardar y cerrar el fichero (en nano, pulsa Ctrl + O, Enter y Ctrl + X).

Fase 3: Compilación y generación del fichero objeto (.ko):

  • Crear un fichero de código en lenguaje C asociado (ej. mi_driver_red.c) que incluya las macros básicas de inicialización y salida del kernel.
  • Ejecutar el proceso de compilación ejecutando la orden: make
  • Inspeccionar el directorio de trabajo tras la compilación y comprobar que se ha generado con éxito el fichero binario con extensión .ko (Kernel Object): ls -l mi_driver_red.ko

Fase 4: Instalación manual, actualización de dependencias y carga con modprobe:

  • Copiar el módulo compilado a la ruta oficial correspondiente del árbol de módulos del kernel en uso (por ejemplo, dentro del directorio kernel/drivers/net/): sudo cp mi_driver_red.ko /lib/modules/$(uname -r)/kernel/drivers/net/
  • Actualizar obligatoriamente la base de datos de dependencias y símbolos del kernel para que el sistema reconozca el nuevo fichero: sudo depmod -a
  • Cargar el módulo recién compilado en caliente utilizando la herramienta inteligente: sudo modprobe mi_driver_red
  • Verificar que el kernel lo ha integrado y está activo ejecutando: lsmod | grep mi_driver_red

Verificación:

  • Comprobar los metadatos y la correcta firma estructural del módulo instalado consultando su información técnica: modinfo mi_driver_red
  • Verificar que el sistema registra la carga correcta sin errores en los logs del kernel ejecutando: dmesg | tail -n 10

Posibles errores y resolución de problemas:

Si al intentar cargar el módulo compilado mediante el comando modprobe el sistema devuelve un error crítico de formato o de versión desajustada (exec format error o invalid module format), significa que las cabeceras utilizadas para compilar no coinciden exactamente con la versión del kernel activo.

  • Solución: Asegúrate de haber instalado los paquetes de cabeceras correspondientes al kernel exacto que devuelve la orden uname -r, limpia los ficheros residuales ejecutando make clean y vuelve a compilar el código fuente desde cero.

Alternativa directa: Descarga y limpieza del módulo personalizado

Si durante las pruebas el módulo compilado provoca un comportamiento inesperado o necesitas retirar la versión de prueba para compilar una modificación en el código fuente, puedes descargar el módulo de la memoria del kernel de forma inmediata con modprobe -r y limpiar los binarios generados:

sudo modprobe -r mi_driver_red
make clean

Preguntas de reflexión:

  1. ¿Por qué es estrictamente necesario ejecutar el comando depmod -a después de copiar manualmente un fichero .ko al directorio de módulos del sistema?
  2. ¿Qué función cumple exactamente el parámetro M=$(PWD) dentro del fichero Makefile estándar utilizado para compilar módulos de kernel fuera del árbol principal (out-of-tree)?
  3. ¿Qué diferencia técnica existe entre los errores de dependencias de símbolos (symbol version mismatch / vermagic) frente a errores de compilación por incompatibilidad de cabeceras?
  4. ¿Qué ventajas operativas aporta compilar un driver como módulo independiente de tipo .ko frente a compilarlo de forma estática dentro de la imagen monolítica del núcleo?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Por qué es estrictamente necesario ejecutar el comando depmod -a después de copiar manualmente un fichero .ko al directorio de módulos del sistema?

Porque el comando depmod analiza todos los módulos disponibles en el sistema y reconstruye los ficheros de índice y dependencias (como modules.dep). Si no se ejecuta, el sistema inteligente modprobe no sabrá que el nuevo módulo existe ni qué otros componentes necesita para funcionar, impidiendo su carga automática.

2. ¿Qué función cumple exactamente el parámetro M=$(PWD) dentro del fichero Makefile estándar utilizado para compilar módulos de kernel fuera del árbol principal (out-of-tree)?

Indica al sistema de compilación del kernel (kbuild) que debe cambiar temporalmente al directorio actual de trabajo (PWD) para buscar el código fuente del módulo externo que se desea compilar, utilizando las reglas y la infraestructura base del kernel ubicado en la ruta de las cabeceras.

3. ¿Qué diferencia técnica existe entre los errores de dependencias de símbolos (symbol version mismatch / vermagic) frente a errores de compilación por incompatibilidad de cabeceras?

El error de compilación ocurre antes de generar el binario debido a que la sintaxis o las estructuras de las cabeceras C no casan con el compilador. Por el contrario, el error de versión (vermagic) ocurre durante la carga (en caliente con modprobe) porque el módulo se compiló usando unas cabeceras cuya versión exacta de kernel difiere de la versión del núcleo que está ejecutándose en ese preciso instante en la máquina.

4. ¿Qué ventajas operativas aporta compilar un driver como módulo independiente de tipo .ko frente a compilarlo de forma estática dentro de la imagen monolítica del núcleo?

Permite actualizar, corregir, parchear o cambiar el controlador de un dispositivo de red o vídeo de forma dinámica y en caliente (sin necesidad de recompilar todo el kernel ni reiniciar el servidor), ahorrando espacio en memoria RAM al cargar el driver únicamente si el hardware físico correspondiente está presente y conectado.