¿Cuál es la diferencia entre los controladores del núcleo y los módulos del núcleo?


67

Cuando hago un lspci -ken mi Kubuntu con un núcleo genérico 3.2.0-29, puedo ver algo como esto:

01:00.0 VGA compatible controller: NVIDIA Corporation G86 [Quadro NVS 290] (rev a1)
    Subsystem: NVIDIA Corporation Device 0492
    Kernel driver in use: nvidia
    Kernel modules: nvidia_current, nouveau, nvidiafb

Hay un controlador del núcleo nvidiay los módulos del núcleo nvidia_current, nouveau, nvidiafb.

Ahora me preguntaba cuál podría ser la diferencia entre los controladores de Kernel y los módulos de Kernel.

Respuestas:


78

Un módulo de kernel es un código compilado que se puede insertar en el kernel en tiempo de ejecución, como con insmodo modprobe.

Un controlador es un bit de código que se ejecuta en el núcleo para comunicarse con algún dispositivo de hardware. Se "impulsa" el hardware. La mayoría de los componentes de hardware de su computadora tienen un controlador asociado. Una gran parte de un núcleo en ejecución es el código del controlador.²

Se puede construir un controlador estáticamente en el archivo del kernel en el disco.³ También se puede construir un controlador como un módulo del kernel para que luego se pueda cargar dinámicamente. (Y luego tal vez descargado).

La práctica estándar es construir controladores como módulos del kernel cuando sea posible, en lugar de vincularlos estáticamente al kernel, ya que eso brinda más flexibilidad. Sin embargo, hay buenas razones para no hacerlo:

  • A veces, un controlador determinado es absolutamente necesario para ayudar al sistema a arrancar. Eso no sucede tan a menudo como te puedas imaginar, debido a la función initrd .

  • Los controladores creados estáticamente pueden ser exactamente lo que desea en un sistema que tiene un alcance estático, como un sistema integrado . Es decir, si sabe de antemano exactamente qué controladores siempre se necesitarán y esto nunca cambiará, tiene una buena razón para no molestarse con los módulos dinámicos del núcleo.

  • Si construye su núcleo de forma estática y deshabilita la función de carga del módulo dinámico de Linux, evitará la modificación en tiempo de ejecución del código del núcleo. Esto proporciona seguridad y estabilidad adicionales a expensas de la flexibilidad.

No todos los módulos del núcleo son controladores. Por ejemplo, una característica relativamente reciente en el kernel de Linux es que puede cargar un planificador de procesos diferente . Otro ejemplo es que los tipos de hardware más complejos a menudo tienen múltiples capas genéricas que se encuentran entre el controlador de hardware de bajo nivel y el país de usuario, como el controlador USB HID , que implementa un elemento particular de la pila USB , independiente del hardware subyacente.


A un lado:

  1. Una excepción a esta declaración general es el chip de CPU, que no tiene "controlador" per se . Su computadora también puede contener hardware para el que no tiene un controlador.

  2. El resto del código en un núcleo del sistema operativo proporciona servicios genéricos como gestión de memoria , IPC , programación , etc. Estos servicios pueden servir principalmente a las aplicaciones de los usuarios , como con los ejemplos vinculados anteriormente, o pueden ser servicios internos utilizados por controladores u otros dispositivos internos. Infraestructura del núcleo.

  3. La entrada /boot, cargada en la RAM en el momento del arranque por el cargador de arranque al principio del proceso de arranque .


1
Los módulos pueden ser sistemas de archivos, protocolos de red, funcionalidades de firewall y mucho más. Algunos hardware (por ejemplo, tarjetas WiFi) requieren una pila de módulos, algunos ofrecen infraestructura general, mientras que otros manejan el hardware en sí.
vonbrand

1
Este es un buen resumen general, pero tenía exactamente la misma pregunta que el OP, luego encontré esta respuesta y aún no sabía por qué el "controlador en uso" es diferente de los "módulos". En contraste, la respuesta de @Jim Paris es correcta. De man lspci: "-k Muestra los controladores del kernel que manejan cada dispositivo y también los módulos del kernel capaces de manejarlo ". Puede leer eso como: "Mostrar el controlador que actualmente maneja el dispositivo y también todos los módulos que podrían / ​​están destinados a manejarlo ".
Binarus

Si conoce Windows: un módulo es muy similar a una DLL. En Unix, un módulo es similar a un objeto compartido, pero un módulo es solo para el núcleo. Un módulo vinculado dinámicamente puede contener controladores. Un kernel puede contener controladores enlazados estáticamente. Un módulo es diferente de una DLL (o .so) porque el núcleo tiene requisitos específicos sobre cómo se cargan las cosas dinámicamente.
robocat

18

Para responder a su pregunta específica sobre el lspciresultado, la línea "controlador del núcleo" se refiere a qué controlador está actualmente vinculado a la tarjeta, en este caso el nvidiacontrolador propietario . La línea "módulos de kernel" enumera todos los controladores que se sabe que pueden vincularse a esta tarjeta. Aquí, el controlador propietario muestra un nombre diferente, probablemente debido a cómo se lspciencontró el controlador y su nombre de archivo versus el nombre codificado en el controlador.


Gracias, eso ayudó. Si solo hubiera emitido man lspci, dice exactamente lo que escribiste.
Binarus

5

De acuerdo con este bonito tutorial :

... un tipo de módulo es el controlador del dispositivo, que permite que el núcleo acceda al hardware conectado al sistema.

Entonces, si tratamos de dibujar un árbol, tendremos un "controlador de dispositivo" que hereda del módulo (se extiende) y que tiene características más específicas, entre las cuales encontramos "acceso al hardware" ...


Esto es solo parcialmente correcto. El controlador es un objeto de una clase en la jerarquía (sí, el diseño interno de Linux, como la mayoría de los sistemas operativos actuales, está orientado a objetos). Pero dicho controlador podría ser un módulo (cargable en tiempo de ejecución) o compilado en el núcleo. No hay (o muy poca) diferencia entre las alternativas, en cuanto al código.
vonbrand

4

Un módulo de kernel puede no ser un controlador de dispositivo en absoluto.

"Controlador de kernel" no es un término bien definido, pero vamos a intentarlo.

Este es un módulo de kernel que no maneja ningún hardware y, por lo tanto, no podría considerarse razonablemente un "controlador de dispositivo":

#include <linux/module.h>
#include <linux/kernel.h>

MODULE_LICENSE("GPL");

static int myinit(void)
{
    printk(KERN_INFO "hello init\n");
    return 0;
}

static void myexit(void)
{
    printk(KERN_INFO "hello exit\n");
}

module_init(myinit)
module_exit(myexit)

Después de compilar, puede usarlo con:

insmod hello.ko

y se imprime hello inita dmesg.

Sin embargo, hay módulos de kernel que no son controladores de dispositivo, pero en realidad son útiles, por ejemplo, módulos que exponen información de depuración / rendimiento del kernel.

Los controladores de dispositivos suelen ser también módulos de kernel.

Un ejemplo de algo que es un "controlador de dispositivo" es un poco más difícil de generar, ya que requiere un hardware para conducir, y las descripciones de hardware tienden a ser complicadas.

Sin embargo, utilizando QEMU u otros emuladores, podemos construir modelos de software de hardware real o simplificado, que es una excelente manera de aprender a hablar con el hardware. Aquí hay un ejemplo simple de un controlador de dispositivo PCI mínimo: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/6788a577c394a2fc512d8f3df0806d84dc09f355/kernel_module/hello.c

Luego vemos que en x86, hablar con el hardware se reduce a:

En general, esas operaciones no se pueden realizar desde el país de usuario, como se explica en: ¿Cuál es la diferencia entre el espacio del usuario y el espacio del kernel? Sin embargo, hay algunas excepciones: https://stackoverflow.com/questions/7986260/linux-interrupt-handling-in-user-space .

El núcleo luego ofrece API de nivel superior para hacer que dicha interacción de hardware sea más fácil y más portátil:

  • request_irq manejar interrupciones
  • ioreadX y mapeo de memoria IO
  • incluso interfaces de nivel superior para protocolos populares como PCI y USB

0

Mi respuesta irá con Jim. Un controlador de kernel es un programa (módulo de kernel) diseñado para controlar una pieza de hardware. La salida de lspci dice que nvidia es el controlador del núcleo, ya que es el loadedmódulo para el dispositivo. Junto con él viene otros módulos de kernel disponibles disponibles.

Agregaré que los comandos en Linux para enumerar y eliminar los controladores son lsmody rmmodrespectivamente. Lo que dice list module y remove module.


0

Todos los controladores son módulos. No todos los módulos son controladores.

Los módulos se pueden insertar en tiempo de ejecución. Los módulos / controladores se pueden compilar estáticamente junto con el núcleo también.

El módulo típico init tiene

module_init(init_fn);
init_fn()
{
   /* some code */
}

El mismo módulo puede convertirse en un controlador

module_init(init_fn);
init_fn()
{
   device_register(&device);
   /* some code */
}

8
Los controladores no siempre son módulos, se pueden incluir en la imagen principal del núcleo.
Gilles 'SO- deja de ser malvado'

3
@Prabagaran: "Todos los controladores son módulos. Todos los módulos no son controladores". Esto es contradictorio. En términos matemáticos, lo que estás diciendo es D -> M y M ->! D. Esto permite D y! D.
Francesco Turco

2
Creo que quiere decir "Todos los controladores son módulos. No todos los módulos son controladores".
Renan

44
@Renan: Eso sería correcto, pero si miras el historial de edición de esta respuesta, alguien ya intentó corregir el error y el autor lo revirtió. Normalmente solo editaría para corregir el error y seguir adelante, pero en este caso lo he hecho porque está mal y confunde el problema.
Caleb

Como recuerdo (no he engañado en mucho tiempo) hay algunos controladores que no se pueden construir como módulos cargables. Me parece recordar a otros que solo pueden manejarse como módulos.
vonbrand
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.