OS structure — monolithic, microkernel, hybrid: Question bank

Two pictures to hold in your head first

Before the traps, lock in the two mental images this whole page keeps testing. There are two separate axes, and almost every trap below lives in the gap between them:

Left picture — the SPEED axis. A request is a traveller climbing walls. The number of walls is $n$ (the boundary-crossing count); the height of each wall is $s$ (the cost of one crossing). Few short walls → fast.
Right picture — the RELIABILITY axis. A separate box whose size is $T$ , the amount of code running privileged. A bigger box means more code that can crash the whole machine.

The figure below draws both. On the left, follow the coral arrow: the green app block hops over two vertical "wall" lines — count them to read $n$ , and the label "each crossing costs $s$ " marks the wall height. On the right, the lavender box is $T$ : its area, not its position, is the quantity that matters. The dashed divider between the panels is the whole point — these are independent measurements, so a design can have a small $n$ (fast) and a huge $T$ (fragile) at the same time, which is exactly what monolithic kernels do.

Formula Rough communication-cost model

$C \approx n \cdot s$ WHY it multiplies, and WHY it looks linear: to first approximation the request crosses $n$ walls, each of roughly equal height $s$ , and there is no shared setup between crossings — each hand-off independently traps, may reschedule, and copies data. "Add up $n$ equal chunks of $s$ " is multiplication, so $C$ grows in a straight line with $n$ . That linear shape is the entire speed argument made quantitative.

WHERE the model bends (important edge cases): the "no shared setup, all crossings independent" assumption is a simplification, not a law. Two effects break it:

Batching / amortization. If several logical operations ride inside one trap (e.g. writev sending many buffers in a single system call, or an IPC that carries a batch of requests), those logical crossings share one setup cost. The true model is closer to $C \approx (setups) \cdot s$ , and batching drives the setup count below the naive $n$ .
Fast-path IPC. Modern microkernels (e.g. L4) implement IPC hops that stay on the same CPU and skip a full context switch when possible, so the effective $s$ for those hops is far smaller than a general crossing. The gap between monolithic and microkernel then shrinks — the model is directional, not exact.

Keep $C \approx n \cdot s$ as the intuition; remember that real systems fight it with batching and fast-path IPC.

The picture below makes the linear shape literal. The x-axis is $n$ (boundary crossings per request), the y-axis is $C$ (total overhead). Because every extra crossing adds the same chunk $s$ , the dots fall exactly on a straight line through the origin. The mint dot marks a monolithic read() ( $n \approx 2$ , low $C$ ); the coral dot marks a microkernel read() ( $n \approx 6$ , high $C$ ). The dashed line is the batched / fast-path case: the same request, but shared setup bends the cost below the straight line — the visual proof that the "strictly linear" assumption is only a first approximation.

True or false — justify

A monolithic kernel cannot be modular.

False — Linux is monolithic yet uses loadable modules; it is modular in source structure but the modules still run in kernel mode, so there is no runtime isolation between them.

In a microkernel, the file-system server runs in kernel mode.

False — the whole point is that the FS runs as an ordinary user-mode server process; only IPC, scheduling, and low-level memory stay privileged.

"Micro" in microkernel means the kernel executes faster because it is small.

False — "micro" describes how little runs in privileged mode (small

T

), not execution speed; pushing services to user space adds boundary crossings, so it is usually slower.

Windows NT is a pure microkernel.

False — it began with microkernel ideas (the Executive) but graphics and file-system code were pulled into kernel space for speed, making it a hybrid.

A hybrid kernel is more reliable than a pure microkernel.

False — by moving hot-path services back into kernel mode a hybrid re-enlarges the trusted code base

T

, so its isolation sits between monolithic and microkernel, not above microkernel.

macOS/XNU is monolithic because it feels like UNIX to programmers.

False — the UNIX-like feel comes from a BSD layer, but XNU combines a Mach microkernel with that BSD chunk, so it is a hybrid.

Two device drivers in a monolithic kernel are protected from each other.

False — both run in the same kernel address space, so a bug in one can corrupt the other's memory; there is no protection boundary between them.

In a microkernel, a crashed driver forces a full machine reboot.

False — a driver is a user-mode server; if it dies the microkernel survives and can restart it, so the machine keeps running.

Every system call is exactly one boundary crossing regardless of kernel structure.

False — one request may need many crossings; in a microkernel a single read() can trigger 4–6+ crossings as it hops through separate servers.

A larger trusted code base always means faster execution.

False —

T

measures how much code can crash you (reliability), not speed; speed tracks the number of boundary crossings

n

, and these are independent quantities.

Batching many operations into one system call can make the real cost fall below

n \cdot s

True — if several logical crossings share a single trap/setup, they no longer each pay the full

s

, so the naive

C \approx n \cdot s

overestimates; the true cost tracks the number of setups, not logical hops.

Spot the error

"Monolithic kernels avoid mode switches entirely, so a read() costs zero crossings."

Wrong — the app still starts in user mode, so it must trap into the kernel and return: about 2 crossings. Monolithic minimizes crossings inside the kernel (function calls), not the initial user→kernel trap.

"Because a microkernel passes messages, context switches are always required on every hop."

Wrong — a general IPC hop does force a context switch, but fast-path IPC (e.g. L4) can stay on the same CPU and skip it, so "always" is too strong; the effective

s

for those hops is much smaller.

"The overhead model

C \approx n \cdot s

says communication cost grows with kernel size."

Wrong —

n

is the number of boundary crossings per request and

s

the per-crossing cost; neither is

T

(kernel size). A big monolithic kernel can have small

n

and thus low

C

"To make Linux a microkernel, just compile the drivers as modules."

Wrong — modules still load into kernel mode. Becoming a microkernel would require running those drivers as isolated user-mode processes talking over IPC, which is a structural change, not a compile flag.

"Hybrids are slow because they use IPC for everything like a microkernel."

Wrong — hybrids deliberately keep hot-path services (the frequently-fired FS and graphics paths) in kernel space precisely to avoid IPC on those paths; that is why they land between monolithic and microkernel in speed.

"A driver bug in QNX (a microkernel) will corrupt the scheduler."

Wrong — the scheduler lives in the tiny privileged core while the driver is an isolated user process; the isolation boundary stops it from touching kernel memory.

Why questions

Why does more code in kernel mode buy speed but cost reliability?

Co-located services talk by plain function calls (few crossings ⇒ low

n

⇒ fast), but any bug among them runs privileged and can crash the whole machine (large

T

⇒ fragile).

Why can't we get microkernel isolation and monolithic speed at once?

Isolation requires a protection boundary between services, and every boundary must be crossed by a trap/IPC that costs time; you are trading crossings for safety, so the two goals pull in opposite directions.

Why did hybrids win the desktop market?

Pure microkernels were too slow in the 1990s and pure monoliths too fragile at scale, so hybrids kept microkernel-style modular structure while running hot-path services in kernel mode for "good enough" speed and safety.

Why does the Inter-process communication (IPC) cost dominate in a microkernel?

Because each service is a separate process, satisfying one request means several IPC hops, and each hop copies data plus (usually) reschedules — so cost scales with the number of hops

n

, which the design makes large.

Why can fast-path IPC shrink the microkernel's disadvantage without changing

n

Because it lowers

s

, not

n

: keeping a hop on the same CPU and skipping the full context switch makes each crossing cheaper, so the same number of crossings costs less overall.

Why is verifying a microkernel's correctness more tractable than a monolithic kernel's?

The trusted core

T

is only a few thousand lines, so there is far less code that must be proven bug-free; everything else runs unprivileged and cannot crash the machine even if wrong.

Why does a trap into the kernel exist at all instead of letting apps touch hardware directly?

Direct hardware access would let any buggy or malicious app corrupt the machine; the trap forces a controlled entry point where the privileged kernel validates the request before acting.

Why is speed measured by

n

but reliability measured by

T

, not the same number?

Speed is about how many walls a request climbs per request (

n

); reliability is about how much code has the power to crash everything (

T

). A design can have a huge

T

yet tiny

n

(monolithic) — proving these are genuinely different axes.

Edge cases

If a request needs zero privileged operations (pure arithmetic in user space), how many boundary crossings does it cost in any structure?

Zero — no trap is needed, so monolithic, microkernel, and hybrid all cost the same; structure only matters once a privileged service is involved.

An OS puts everything, including apps, in kernel mode (no user mode at all). What have you built?

A single-privilege system with maximal

T

and no isolation — effectively an extreme monolithic design where any bug anywhere can crash everything; this is why early/embedded systems without an MMU are so fragile.

A "microkernel" that keeps its file system in kernel mode for speed — what is it really?

A hybrid, by definition, because it has already violated the microkernel rule that only IPC/scheduling/memory stay privileged; the label follows the structure, not the marketing.

In the model

C \approx n \cdot s

, what happens to

C

n \to 0

C \to 0

— a request needing no boundary crossings has essentially no communication overhead, which is the limiting best case any structure shares.

If per-crossing cost

s

were driven to nearly zero by fast-path IPC hardware, would the monolithic-vs-microkernel speed gap survive?

No — since

C \approx n \cdot s

, a tiny

s

shrinks the penalty of large

n

, so the microkernel's extra crossings would barely matter; this is exactly the argument modern fast-IPC microkernels (like L4) make.

If ten logical operations are batched into a single trap, what does

n

effectively become for the cost model?

Effectively one setup rather than ten, so

C

tracks the number of shared setups, not the ten logical hops — the batched cost falls below the naive

10 \cdot s

A single request that would need 2 crossings in monolithic and 6 in microkernel — what is the microkernel's overhead ratio?

Roughly

6 s /2 s = 3 \times

the communication cost, showing the penalty is the ratio of crossings, independent of the constant

s

Recall One-line self-test before you leave

Speed order, reliability order, and what each tracks? Speed MONO > HYBRID > MICRO, driven by the crossing count $n$ ; reliability is exactly reversed (MICRO > HYBRID > MONO), driven by the trusted-base size $T$ — a different quantity from $n$ , which is why the two orderings are opposites rather than the same measurement.