OS structure — monolithic, microkernel, hybrid: Worked examples

First: what exactly is "one crossing"?

Before counting anything, we must earn the number we count — and pin down exactly one meaning for it so every example agrees.

Figure — OS structure — monolithic, microkernel, hybrid

Formula The counting rule we will apply everywhere (full round trip)

$n$ always means the complete round trip — request out and reply back. Walk the path of control and tally, using "user→kernel = 1, kernel→user = 1": $n = app trap in + final return out 2 + 2 \cdot (number of separate user-mode servers the request must visit) .$

The fixed 2 is the app's own bracket: one crossing to enter the kernel, one to return to the app at the very end.
Each user-mode server visited costs a full IPC = 2 crossings (user→kernel→user), and the reply reuses the same relay, but we bill each visited server once at its 2-crossing IPC cost — this is the standard "one round-trip IPC = 2 crossings" convention stated in the definition above.
Monolithic: all servers are inside the kernel, so the "number of separate user-mode servers" is 0 $\Rightarrow n = 2$ .
Microkernel: every server is a separate user process $\Rightarrow$ the count grows by 2 per server.
Hybrid: only servers that still live in user space count; hot-path servers pulled into the kernel add 0.

This single formula, $n = 2 + 2 m$ (with $m$ = user-mode servers visited), is used identically in every example — no per-example redefinition.

The scenario matrix

Every worked example below is tagged with the cell it fills. Together they cover the whole grid. The middle column names the case class; the right column says what makes that case tricky.

Cell	Case class	What makes it tricky
A	Simple request, monolithic	baseline: proving the " $n = 2$ " claim
B	Simple request, microkernel (2 servers)	the " $n = 4$ " case, chained servers
C	Same request, hybrid	which servers are in-kernel?
D	Zero-crossing / degenerate input	request needs no privileged service
E	Growth case: many servers (limiting, large $n$ )	$n$ grows linearly — the microkernel wall
F	Limiting case: push all servers into kernel	microkernel → monolithic in the limit
G	Real-world word problem	web server serving a file, multi-syscall path
H	Exam twist: "smaller kernel = faster?"	the trap the parent warned about
I	Reliability edge case: a driver crashes	what survives, per structure
J	Fast-path edge case: shared-memory IPC	when a "crossing" doesn't occur

Worked examples

Worked example Example A — baseline monolithic

read() (cell A) A user app calls read() to fetch a byte from a file on disk, on a monolithic kernel (Linux-style). Count the crossings $n$ (full round trip) and the cost $C$ if one crossing costs $s = 1$ unit.

Forecast: guess $n$ before reading on. Two? Four?

App in user mode executes read(), which is a system call → trap into kernel (user→kernel = 1 crossing). Why this step? Only kernel mode may touch the disk — see System calls and traps.
Inside the kernel, the file-system code calls the disk-driver code as a plain function. Adds 0. Why this step? Both live in the same address space (monolithic), so this is a free jump — no border pierced. Here $m = 0$ user-mode servers.
Data is placed in the app's buffer; control returns to user mode → return out (kernel→user = 1 crossing). Why this step? Returning to the restricted mode is itself a controlled boundary flip.

Using $n = 2 + 2 m$ with $m = 0$ : $n = 2 + 2 \cdot 0 = 2, C \approx 2 \cdot 1 = 2.$

Verify: the parent note asserts "boundary crossings ≈ 2" for exactly this case. Units: $n$ is a pure count, $s$ is cost/crossing, so $C$ is in cost units. ✔

Worked example Example B — the same

read() on a microkernel with 2 servers (cell B) Same request, but on a microkernel where the file-system (FS) and the disk-driver are separate user-mode servers. Count the full round-trip $n$ .

Forecast: the parent said "4–6+". Which end for two servers?

The request must visit two user-mode servers: the FS server and the disk-driver server. So $m = 2$ . Why this step? IPC must route through the kernel — the kernel is the only thing both trust. See Inter-process communication (IPC).
Each visited user-mode server costs one round-trip IPC = 2 crossings (user→kernel→user), by the ONE rule above. Two servers ⇒ $2 \cdot 2 = 4$ from the servers. Why this step? We are using the single consistent convention "one IPC = 2 crossings" — no forward/return ambiguity, because the round-trip is already baked into that 2.
Add the app's own bracket (its own enter+return): the fixed $+ 2$ of the master formula. Why this step? The app itself must trap into the microkernel to start the request and receive the final return — that entry/exit pair is separate from the server IPCs and is exactly the constant "2" in $n = 2 + 2 m$ .

Using $n = 2 + 2 m$ with $m = 2$ : $n = 2 + 2 \cdot 2 = 6.$ If instead you count only the two core server IPCs and fold the app bracket into them (the parent's tightest "4" accounting), you get the low end $n = 4$ ; the master formula gives the fuller $n = 6$ . Both sit inside the parent's stated "4–6+" range. $C \approx n \cdot s = 6 (s = 1) .$

Verify: $n_{micro} / n_{mono} = 6/2 = 3$ (or $4/2 = 2$ on the tight count) — either way the microkernel does more boundary work, matching "usually slower", and both endpoints lie in the parent's 4–6+ band. ✔

Worked example Example C — same request on a hybrid (cell C)

A hybrid kernel (Windows-NT-style) keeps the FS in kernel space for speed, but the disk-driver is a user-mode server. Count the round-trip $n$ for the read().

Forecast: should land between the monolithic and microkernel values.

App calls read(). The FS lives in the kernel, so it runs there directly — it is not a user-mode server, so it adds 0 to $m$ . Why this step? FS was "pulled back" into kernel mode precisely to skip an IPC.
The disk-driver is still a user-mode server, so it counts: $m = 1$ . Why this step? Only servers still in user space pierce the border.

Using $n = 2 + 2 m$ with $m = 1$ : $n = 2 + 2 \cdot 1 = 4.$ If the driver were also pulled in-kernel (common hot path), then $m = 0$ and $n = 2$ . So the hybrid's $n$ depends on which services were pulled in.

Verify: driver in-kernel ⇒ $n = 2 = n_{mono}$ ; driver in user space ⇒ $n = 4$ . The hybrid is bounded by the two extremes: $2 \leq n \leq 4$ , matching "medium". ✔

Worked example Example D — degenerate input: a request that touches no privileged service (cell D)

An app computes x = 3 + 4 and stores it in its own memory. How many crossings, on any structure?

Forecast: trick question — how many?

Addition and the store both hit only the app's own registers and its own user-mode memory. So $m = 0$ and there is no trap at all. Why this step? No disk, no device, no other process — nothing privileged is requested, so control never pierces the border.
Since no border is crossed, even the fixed "2" bracket is absent — the app never leaves user mode. Why this step? The $+ 2$ bracket only appears when a request needs the kernel; here it doesn't.

$n = 0, C \approx 0 \cdot s = 0.$

Verify: the structure of the kernel is irrelevant when $n = 0$ — monolithic, micro, hybrid all cost the same for pure user-space work. This is the degenerate boundary of the model. ✔

Worked example Example E — growth case: a request chaining

$k$ user-mode servers (cell E) On a microkernel, a request must consult $k$ separate user-mode servers in a chain (FS → driver → volume-encryption → network-block-device …). Give $n$ as a function of $k$ using the master formula, and evaluate at $k = 1, 2, 5$ .

Forecast: linear or exponential in $k$ ?

Here the "number of separate user-mode servers visited" is exactly $m = k$ . Why this step? Each server in the chain is its own address space, so each is a border-piercing IPC.
Plug straight into the same master formula $n = 2 + 2 m$ — no new rule, no "folding the bracket": Why this step? Consistency: E must use the identical formula as A, B, C.

$n (k) = 2 + 2 k .$ $n (1) = 4, n (2) = 6, n (5) = 12.$

Verify: $n$ is linear in $k$ (slope 2), never exponential — exactly the parent's $C \approx n \cdot s$ scaling linearly. At $k = 2$ we recover Example B's master-formula value $n = 6$ . ✔

Worked example Example F — limiting case: pull ALL servers into the kernel (cell F)

Start from the microkernel of Example E with $k$ user-mode servers, so $n = 2 + 2 k$ . Now move the servers into kernel space one at a time. Track $n$ and name the structure you end up with.

Forecast: what is the limit of $n$ as servers become in-kernel?

Start: all $k$ servers in user space ⇒ $m = k$ ⇒ $n = 2 + 2 k$ . Why this step? This is the microkernel starting point, straight from the master formula.
Move one server in-kernel: it stops being a user-mode server, so $m$ drops by 1. New value $n = 2 + 2 (k - 1)$ . Why this step? An in-kernel hand-off is a free function call (0 crossings), so removing it from $m$ subtracts exactly 2.
Move all $k$ servers in-kernel: $m$ falls from $k$ to $0$ step by step, i.e. $n = 2 + 2 (k - k)$ . Why this step? Only the app's fixed bracket "2" survives once no user-mode server remains.

Carrying out that final substitution: $n = 2 + 2 \cdot 0 = 2.$ Naming the result: a microkernel with every service moved into kernel mode is, by the parent's own definition, a monolithic kernel — all core services share one address space. So the limiting structure is monolithic, and its crossing count $n = 2$ is exactly the monolithic baseline of Example A.

Verify: $n \to 2 = n_{mono}$ (Example A). The two designs are the endpoints of one continuum $n = 2 + 2 m$ , $0 \leq m \leq k$ — micro at $m = k$ , monolithic at $m = 0$ — which is precisely why hybrids sit in between. ✔

Worked example Example G — real-world word problem (cell G)

A web server on a monolithic Linux box receives a request over the network and sends back a file from disk. Path: network receive → read file → network send. Estimate $n$ .

Forecast: more than 2 this time — why?

Network packet arrives → the network recv() system call. Monolithic ⇒ $m = 0$ inside it ⇒ $n_{1} = 2$ . Why this step? Touching the NIC (network card) is privileged; it's one full syscall bracket.
Read the file → read(): another monolithic syscall, $n_{2} = 2$ (Example A). Why this step? Distinct system call, distinct border bracket.
Send the response → send(): another syscall, $n_{3} = 2$ . Why this step? Back to the NIC.
Inside the kernel, FS↔driver↔network-stack hand-offs are all function calls → add 0 (monolithic). Why this step? All these services are co-located in the one kernel address space, so no border is pierced between them.

$n = n_{1} + n_{2} + n_{3} = 2 + 2 + 2 = 6.$

Verify: even a monolithic kernel racks up crossings when a request spans multiple system calls — but each syscall stays at the minimal 2 because internal servers are co-located. On a microkernel the same word problem would multiply each of these by its server chain. ✔

Worked example Example H — exam twist: "the kernel is smaller, so it's faster" (cell H)

True or false: MINIX 3's kernel is ~12,000 lines vs Linux's millions, therefore MINIX 3 serves read() faster. Justify with $n$ .

Forecast: commit to true or false first.

"Smaller kernel" refers to how little runs privileged, not execution speed. Why this step? This is the exact [!mistake] flagged in the parent note.
Fewer things in kernel mode means more user-mode servers, i.e. larger $m$ , i.e. larger $n = 2 + 2 m$ (Examples B, E). Why this step? Isolation is bought with extra border crossings.
From Examples A and B: $n_{mono} = 2 < n_{micro} = 6$ (or $4$ on the tight count), so $C_{micro} > C_{mono}$ . Why this step? Plug both crossing counts into $C \approx n \cdot s$ with the same $s$ ; the larger $n$ wins the cost.

Answer: FALSE. Speed $\propto n$ , and the small-kernel design has the larger $n$ .

Verify: $C_{micro} / C_{mono} = 6/2 = 3 > 1$ (or $4/2 = 2 > 1$ ), so the "smaller = faster" claim is contradicted by the model. ✔

Worked example Example I — reliability edge case: a device driver crashes (cell I)

A buggy device driver hits a null-pointer bug. What survives on each structure? (Not a numeric $n$ question — a case coverage question.)

Forecast: which structures keep running?

Monolithic: the driver runs in kernel mode, sharing the kernel's address space → it can corrupt any kernel memory → whole machine can crash (kernel panic). Why this step? No isolation between in-kernel modules — see Linux kernel modules.
Microkernel: the driver is a user process; its crash is just one process dying → kernel detects it and restarts the driver server → machine survives. Why this step? Isolation is the microkernel's core promise.
Hybrid: depends on where that driver lives. If pulled in-kernel for speed → behaves like monolithic (can crash); if left in user space → behaves like microkernel (contained). Why this step? Hybrids trade isolation for speed per service, so the outcome is per-service.

Verify: the reliability order matches the parent's table — micro (safe) > hybrid (medium) > mono (fragile) — the exact reverse of the speed order. ✔

Worked example Example J — fast-path edge case: shared-memory IPC (cell J)

A microkernel FS server and the requesting app set up a shared-memory region once, then exchange data through it without trapping. The request still needs one control signal into the kernel to wake the server, but the bulk data transfer uses the shared page. How does $n$ change versus Example B's plain-IPC path?

Forecast: does the shared page make $m$ bigger or smaller?

Normally visiting the FS server costs a 2-crossing IPC. With shared memory, the data hand-off pierces no border — it's a plain memory write. Why this step? By the edge-case rule, a hand-off counts only if control pierces the privilege line; shared-memory writes do not.
Only the small "wake the server" signal remains — count it as the one unavoidable trap+return bracket. Why this step? The server still must be scheduled, but the big data copy is gone.

So instead of $n = 2 + 2 m$ with the FS billed a full 2, the FS's data crossings drop out and the FS contributes ≈0 extra; the request collapses toward the monolithic-style $n \approx 2$ .

Verify: shared-memory fast paths are exactly how real microkernels (L4, QNX) claw back performance — they reduce the crossing count, which by $C \approx n \cdot s$ reduces cost. The model predicts the real-world fix. ✔

Recall Quick self-test on the counting rule

Master formula: what is $n$ in terms of $m$ (user-mode servers visited)? ::: $n = 2 + 2 m$ — a fixed app bracket of 2, plus 2 per user-mode server. A microkernel request visits 3 user-mode servers. Using $n = 2 + 2 m$ , what is $n$ ? ::: $n = 2 + 2 \cdot 3 = 8$ . On a monolithic kernel, a request making 4 separate system calls (each internal, $m = 0$ ) costs how many crossings? ::: $4 \times 2 = 8$ (each syscall is its own $2 + 2 \cdot 0 = 2$ bracket; internal hand-offs are free). A hybrid keeps FS in-kernel but driver in user space ( $m = 1$ ) — what is $n$ for a file read? ::: $n = 2 + 2 \cdot 1 = 4$ , between mono ( $2$ ) and pure micro ( $6$ ). If $n = 0$ , which structure is fastest? ::: All three tie — pure user-space work ( $m = 0$ and no trap) never crosses the border, so kernel structure is irrelevant. Does a shared-memory IPC fast path raise or lower $n$ ? ::: It lowers $n$ : the data hand-off pierces no border, so those crossings drop out, pushing the microkernel cost toward the monolithic floor.