e_opore explains Linux kernel modules
- Emmanuel Opore posted an explainer on X describing how Linux stays monolithic while still accepting loadable kernel modules for drivers and filesystems. - He focused on modules as code loaded into the running kernel, where exported symbols let separate pieces connect without rebuilding Linux. - Linux vendors document the same model: add drivers or filesystems without rebooting or recompiling. (docs.redhat.com)
Linux’s kernel is one big program in memory, but it can still accept new pieces while the system is running. Those pieces are called loadable kernel modules. (docs.redhat.com 1) (docs.redhat.com 2) Developer Emmanuel Opore used that design to explain why Linux is described as monolithic and modular at the same time. His thread framed modules as plug-in code for drivers, filesystems, and other kernel features. (x.com 1) (x.com 2) In Linux, a monolithic kernel means core services run in one kernel address space instead of being split into separate user-space servers. Red Hat’s documentation says Linux is monolithic by design, with optional capabilities added as dynamically loaded modules. (docs.redhat.com) A module is compiled separately, then inserted into the running kernel when hardware or a feature needs it. Red Hat says that can add device-driver or filesystem support without recompiling the whole kernel or rebooting the machine. (docs.redhat.com) The speed argument comes from where the code runs. Because a module executes inside kernel space after it is loaded, it can call kernel functions directly instead of crossing process boundaries the way a microkernel-style design would. (docs.redhat.com) (kernel.org) That is where symbol exports enter the picture. The Linux manual page for `/proc/kallsyms` says the file holds exported symbol definitions used by module tools to dynamically link and bind loadable modules. (man7.org) Kernel build rules reflect that separation. The official `kbuild` documentation says `obj-m` marks object files that should be built as loadable kernel modules, whether the module comes from one source file or several. (kernel.org) For anyone debugging hardware support, the practical lesson is narrow and concrete: check how the module is built, how it loads, and which symbols it expects to resolve. The current Linux Kernel Module Programming Guide puts those basics near the front, before moving into drivers, interrupts, and debugging interfaces. (sysprog21.github.io) (github.com) That is why Opore’s explainer landed on modules instead of the whole kernel tree. In Linux, a missing driver often starts as a missing module, a failed load, or an unresolved symbol. (x.com) (man7.org)
