a monolithic kernel

When you build the part of the OS that runs with full hardware privilege, you face a basic design choice: put everything in there together, or keep only a tiny core privileged and push the rest out. A monolithic kernel takes the first path — the scheduler, memory manager, file systems, device drivers, and network stack all run together in one privileged program sharing one address space. Think of a single large hospital building where every department — surgery, pharmacy, records, kitchen — is under one roof; staff walk straight from one to another, no appointments needed, which is fast, but a fire in one wing endangers the whole building.

Concretely, in a monolithic kernel the subsystems call each other as ordinary function calls inside the same memory space. When your program reads a file, the system-call entry, the file-system code, the block-device layer, and the disk driver all run in kernel mode and simply call one another directly, with no boundary crossings between them — which is very fast. Linux is the famous example, and it is monolithic but modular: most of its code is monolithic, yet it can load and unload drivers and features as kernel modules at runtime, so it gains flexibility without giving up the single-address-space speed.

It matters because this is one side of the great structural debate in OS design, set against the microkernel. The monolithic strength is performance and simplicity of communication; the honest weakness is robustness and security: since everything shares one privileged address space, a bug in any driver can corrupt memory anywhere and crash the entire system, and the huge trusted code base is hard to fully verify. A common misconception is that monolithic means non-modular or old-fashioned — Linux shows a monolithic kernel can be highly modular and thoroughly modern; the label is about where the code runs (one privileged space), not how it is organized in source.