How does the Linux kernel know which drivers to load at boot?

I'd like to know this for the first boot and for subsequent boots.

I'm compiling my own kernel and want it to be as lean as possible. I want to build the .config file by hand (mainly as a learning experience), so I need to know everything that can be excluded. I know a possible solution is to look at my current distros list of loaded drivers. However, I'm curious about how my distro discovered what drivers to load initially.

The kernel generates events for devices on e.g. the PCI bus when they are plugged (either hot or cold; events are queued until userspace runs AFAIR). udev will receive these events and do modprobe calls which include the PID/VID (product/vendor IDs) of the device(s); this is usually a string with some * in it. modprobe will then calculate the intersection of the set expressed by udev's load request wildcard and the set of aliases of kernel modules (themselves being possibly wildcards).

Since USB/Firewire/etc. controllers are usually attached to the PCI bus, that's how your HCI driver gets loaded. That is how things recurse down; loading is then done with USB/Firewire PID/VIDs of course.

Network protocol modules (e.g. ipv6) are however not dealt with through udev; instead, when a program calls socket(AF_INET6, ...) the kernel directly calls modprobe (more precisely: whatever is in /proc/sys/kernel/modprobe) with a non-wildcarded alias, net-pf-10 in case of IPv6, because AF_INET6 happens to have value 10. modprobe then loads ipv6.ko, because that is what has the net-pf-10 alias.

Similarly for filesystems, attempting to mount -t foo will cause the kernel to also call modprobe (again, via ____call_usermodehelper), this time with foo as argument.

Accessing device nodes (e.g. /dev/loop0, provided it already exists) has the same strategy if loop.ko is not already loaded. The kernel here requests block-major-7-0 (because loop0 usually has (7,0), cf. ls -l), and loop.ko has the fitting block-major-7-* alias.

=====================================================
之前，该功能的实现是由 kerneld（以及后来的kmod） 完成的，现在由 udevd + kernel call call_usermodehelper 完成.

Kmod: The Kernel Module Loader
Kirk Petersen

Kmod is a simple replacement for kerneld.  It consists of a 
request_module() replacement and a kernel thread called kmod.  When the
kernel requests a module, the kmod wakes up and execve()s modprobe,
passing it the name that was requested.

===========================================================

Name

call_usermodehelper — prepare and start a usermode application

Synopsis

int call_usermodehelper (	char * path,
	char ** argv,
	char ** envp,
	int wait);

 

Arguments

path

path to usermode executable

argv

arg vector for process

envp

environment for process

wait

wait for the application to finish and return status. when UMH_NO_WAIT don't wait at all, but you get no useful error back when the program couldn't be exec'ed. This makes it safe to call from interrupt context.

Description

This function is the equivalent to use call_usermodehelper_setup and call_usermodehelper_exec.