kernel structuring approaches
Once you accept that a kernel has many jobs — scheduling, memory, files, devices, networking — a natural question is how to organize all that code internally. This is the question of kernel structure, and the major answers are monolithic, layered, microkernel, modular, and hybrid. The trade-off running through all of them is the same tension: put more code together in the privileged kernel for speed and simplicity of communication, or pull code apart into separate protected pieces for robustness and security. There is no single winner; each design buys one virtue by spending another.
Here is the orientation-level tour. A monolithic kernel puts all the OS services in one big program running in kernel mode; calls between parts are fast plain function calls, but a bug anywhere can crash everything, and the code base is large (classic Unix, and Linux at its core, are monolithic). A layered design organizes the kernel into ordered layers, each using only the one below — clean to reason about, but rigid and sometimes slow. A microkernel keeps only the bare minimum in kernel mode (basic scheduling, memory, and message passing) and moves services like file systems and drivers out into separate user-space programs that talk by sending messages; a crash in a user-space driver no longer takes down the kernel, and the small core can even be formally verified, but all that message passing adds overhead. A modular kernel keeps a core but loads optional pieces (modules, such as a driver for a device you just plugged in) on demand at runtime. A hybrid kernel mixes the styles — keeping a microkernel-like organization but running performance-critical services in kernel mode anyway (Windows and macOS take broadly hybrid approaches).
Why does a beginner need this map? Because it explains real differences you will hear about — why one system is praised for speed and another for reliability, why a buggy graphics driver can blue-screen one OS but merely restart a service on another. The honest point to carry away is that a microkernel is not automatically better: it trades raw performance (more crossings and message passing) for stronger isolation and easier verification, while a monolithic kernel makes the opposite bet. Most real systems are pragmatic hybrids precisely because no single pure structure wins on every axis at once.
A graphics driver has a bug. In a monolithic kernel where the driver runs in kernel mode, the crash can take down the whole system. In a microkernel where that driver runs as an isolated user-space server, the OS can detect the failure and simply restart that one server, and you barely notice.
Where you put a driver decides whether its bug crashes the world or one server.
A microkernel is not automatically better — it buys isolation and verifiability with extra IPC overhead, while a monolithic kernel buys speed with a larger trusted, crash-exposed core. Most shipping systems are pragmatic hybrids.