a loadable kernel module
/ L-K-M /
A kernel could in principle have every driver and feature compiled permanently into one giant program — but then supporting a new device would mean rebuilding and rebooting the whole kernel, and every machine would carry code for hardware it does not have. A loadable kernel module is the alternative: a chunk of kernel code that can be inserted into, and removed from, a running kernel on demand. Think of a power tool with interchangeable bits: the tool body (the core kernel) stays put while you click in just the drill bit or screwdriver head you need right now, and pop it out when you are done.
Concretely, a module is compiled separately into a file (a .ko file on Linux). When you load it (for example with modprobe or insmod), the kernel links the module's code and data into its own address space at runtime, runs the module's init function to register what it provides (a new device driver, a file-system type, a network protocol), and from then on the module runs with full kernel privileges as if it had always been part of the kernel. When it is no longer needed, the kernel runs the module's exit function and unlinks it, freeing the memory. Drivers are the most common modules: plug in a USB device and the kernel can autoload the matching driver module.
It matters because modules give a monolithic kernel much of the flexibility of a more modular design without giving up the speed of running in one privileged address space — you ship a small core and load only what each machine needs. The crucial honest caveat is the security and stability cost: a module runs with full kernel privilege in the kernel's own address space, so a buggy or malicious module can crash or compromise the entire system. That is why production kernels often require modules to be cryptographically signed before they will load.
You plug in a Wi-Fi dongle. The kernel matches its device ID, runs modprobe to load the right driver module (say iwlwifi.ko), the module's init registers the network device, and the dongle appears as a usable interface — no reboot, no rebuilt kernel. Run lsmod and you can see all currently loaded modules and what depends on what.
Insert driver code into a running kernel on demand; remove it when no longer needed.
A module is not sandboxed: it runs in kernel space with full privileges, sharing the kernel's address space. This is the opposite of a microkernel's user-space driver, which runs as an isolated process — the module is faster but a single bug can take down the machine.