On Linux, what is a loadable kernel module, and how does a driver compiled as a module (=m) differ at runtime from the same driver built into the kernel image (=y)?

## The kernel is not one monolithic binary in practice The Linux kernel is architecturally monolithic — everything runs in one privileged address space, unlike a microkernel where drivers are separate user-space servers. But it is *not* one indivisible file. Most driver, filesystem and protocol code is compiled into separate object files with a `.ko` extension ("kernel object") that can be linked into the running kernel and later unlinked, without a reboot. Every kernel config symbol that supports it has three states: `n` (not built), `m` (built as a loadable module), `y` (built into the kernel image). The *code* is identical; only the packaging differs. ## Where modules live Modules for a given kernel live under `/lib/modules/<kernel release>/`, where the release string is what `uname -r` prints. Inside it there is a `kernel/` directory tree mirroring the kernel source layout (`kernel/fs/`, `kernel/drivers/net/`, …), plus generated index files such as `modules.dep`, `modules.alias` and `modules.builtin`. That last file is worth knowing: it lists what was compiled in with `=y`, which is how `modprobe` can be asked for a built-in feature and quietly report success instead of an error. Because the tree is keyed by kernel release, every installed kernel has its own set of modules. A module built for one kernel is not visible to another. ## Loading is not a user-space thing Once inserted, a module is kernel code in kernel mode. It has no memory protection from the rest of the kernel, can touch any physical address, and a null-pointer dereference in it is an oops or a panic, not a crashed process. That is why loading requires the `CAP_SYS_MODULE` capability — being able to load a module is, in practice, being able to do anything. Modules also carry a licence declaration. Loading a module that is not GPL-compatible, or one that was built outside the kernel tree, sets a *taint* flag in the kernel that persists until reboot; distributions and upstream developers use taint to decide whether a bug report is theirs to fix. ## Who actually types `modprobe`? Usually nobody In day-to-day operation, modules are loaded on demand. Two mechanisms dominate: - **Device-driven autoload.** When the kernel discovers hardware it exports a `modalias` string describing it (bus type, vendor and device IDs). The device manager matches that string against the `modules.alias` index and loads the module that claims it. - **Feature-driven autoload.** When the kernel needs a capability it does not have — mounting a filesystem type, using a network protocol — it asks user space to load the module registered under a well-known alias for that feature. That is why a freshly booted machine usually shows a few dozen loaded modules that nobody asked for by name. ```bash lsmod # modules loaded right now, with reference counts modinfo overlay # file path, licence, parameters, vermagic ls /lib/modules/$(uname -r)/kernel/fs # the on-disk module tree for this kernel grep overlay /lib/modules/$(uname -r)/modules.builtin # or was it compiled in? ``` ## What `=y` buys and what it costs Built-in code is present before any filesystem is mounted, which matters for anything needed to *reach* `/lib/modules` in the first place: the disk controller, the root filesystem driver, sometimes the crypto for an encrypted root. Distributions solve that differently — they keep those as modules and ship them inside the initramfs, a small archive the boot loader hands to the kernel — but embedded and appliance kernels frequently just build them in. The costs of `=y` are real: - It cannot be unloaded. `rmmod` has nothing to remove; the code is not a module and does not appear in `/proc/modules`. - It cannot be blacklisted. Configuration that suppresses module autoloading has no effect on code already inside the image; disabling it needs a kernel command-line switch the driver itself implements, or a different kernel. - Its parameters can only be given on the kernel command line, not at load time, because there is no load time. - It occupies memory whether or not the hardware exists. ## The distinction interviewers are testing The wrong mental model — "a module is a plugin that runs in a safe sandbox" or "a module is a background service" — leads to bad reasoning about everything downstream: why an unsigned module is a security event, why a driver bug takes the whole box down, why a module built for another kernel refuses to load. Get the model right first: a module is the *same* kernel code, delivered late.