| Lesson 2 | Linux: A Monolithic Kernel with Loadable Modules |
| Objective | Distinguish kernel architecture from the choice between built-in features and loadable modules. |
Linux: A Monolithic Kernel with Loadable Modules
Linux uses a monolithic kernel architecture with support for loadable modules. These descriptions answer different questions. Monolithic describes where core operating-system services execute and interact. Loadable describes how selected pieces of kernel code are packaged and introduced into the running system.
Loading a driver as a module does not move that driver into an isolated user-space process. Its code still executes with kernel privileges. Conversely, building a driver into the kernel does not require including every possible device driver.
Built in, loadable, or omitted
| Configuration choice | Result | Administrative consequence |
|---|---|---|
y / built in | The feature is linked into the kernel image. | It is available without loading a separate module and cannot be removed with modprobe -r. |
m / module | The feature is built as a separate module. | It must be installed for the appropriate kernel and loaded when needed. |
n / omitted | The feature is not built. | Loading a module cannot recover code that was never provided. |
Only configuration options that support a modular form offer m. Dependencies may restrict the choices shown by the configuration editor. Distribution kernels commonly provide many drivers as modules so one kernel package can serve different machines.
Consider the boot path
Code needed to reach the root filesystem must be available early enough. It may be built into the kernel, or supplied as modules in an initramfs, the temporary early-boot filesystem. For example, a storage driver compiled as a module cannot help mount the real root filesystem if that driver is accessible only inside the filesystem that has not yet been mounted.
This makes configuration a dependency decision, not a rule that every feature should be modular. Review storage, filesystem, encryption, and other boot requirements together.
Memory, sharing, and trust
A loadable module consumes memory when loaded. Code that is never loaded can avoid that runtime cost, but a modular build is not automatically faster. Actual memory use and performance depend on configuration and workload.
Multiple devices can use one loaded driver. The driver manages device-specific state; the kernel does not normally load another copy of its module code for each device. Reference counts and active users also influence whether a module can be unloaded.
Because modules execute in kernel space, a defective driver can affect the whole system. Signature verification helps establish whether code is trusted under the configured policy; it does not prove that the code is bug-free.
Historical illustrations: built-in and loadable code
These older diagrams use “modular” and “monolithic” as opposing labels. Read them only as a simplified comparison of separately loadable code and code included in an image. Linux supports both while remaining monolithic in architecture.
Red Hat Linux Server
The next lesson shows how to determine which modules are available and which are currently loaded.
References
- RHEL 10: Managing kernel modules
- Linux kernel documentation: Module signing
- Linux kernel documentation: Configuration targets