¿Cómo sabe el kernel de Linux qué controladores cargar en el arranque?

Question

Me gustaría saber esto para la primera bota y para botas posteriores.

Estoy compilando mi propio núcleo y quiero que sea lo más delgado posible. Quiero construir el archivo .config a mano (principalmente como una experiencia de aprendizaje), así que necesito saber todo lo que se puede excluir. Sé que una posible solución es mirar mi lista actual de controladores cargados. Sin embargo, tengo curiosidad sobre cómo mi distribución descubrió qué controladores cargar inicialmente.

TIA.

Answer 1

Greg Kroah ofrece un excelente ejemplo de cómo encontrar exactamente qué controladores necesita para su kernel. Greg amablemente da su libro de forma gratuita en línea

http://files.kroah.com/lkn/

Una cita de los libros de Greg

I'm especially proud of the chapter on how to figure out how to configure 
a custom kernel based on the hardware running on your machine. This is an 
essential task for anyone wanting to wring out the best possible speed and 
control of your hardware. 

Answer 2

¿Cómo sabe el núcleo de Linux, que los conductores de carga en el arranque?

El kernel genera eventos para los dispositivos, p. el bus PCI cuando están enchufados (ya sea caliente o frío, los eventos están en cola hasta que userspace ejecuta AFAIR). udev recibirá estos eventos y realizará llamadas a modprobe que incluyen el PID/VID (identificaciones de producto/vendedor) de los dispositivos; esto es generalmente una cadena con algunos * en ella. modprobe calculará entonces la intersección del conjunto expresado por el comodín de solicitud de carga de udev y el conjunto de alias de los módulos del kernel (posiblemente sean comodines).

Desde USB/Firewire/etc. los controladores generalmente están conectados al bus PCI, así es como se carga el controlador HCI. Así es como las cosas se vuelven a caer; la carga se realiza con USB/Firewire PID/VID por supuesto.

Sin embargo, los módulos de protocolo de red (por ejemplo, ipv6) no se tratan a través de udev; en cambio, cuando un programa llama a socket(AF_INET6, ...) el kernel llama directamente a modprobe (más precisamente: lo que está en /proc/sys/kernel/modprobe) con un alias no comodín, net-pf-10 en caso de IPv6, porque AF_INET6 tiene valor 10. modprobe carga ipv6.ko, porque eso es ¿Qué tiene el alias net-pf-10?

De manera similar para los sistemas de ficheros, tratando de mount -t foo hará que el kernel para llamar también modprobe (de nuevo, a través de ____call_usermodehelper), esta vez con foo como argumento.

El acceso a los nodos del dispositivo (por ejemplo, /dev/loop0, si ya existe) tiene la misma estrategia si loop.ko no está cargado. El kernel aquí solicita block-major-7-0 (porque loop0 generalmente tiene (7,0), consulte ls -l), y loop.ko tiene el alias block-major-7-* correspondiente.