re-org docs

docs/device-driver-development/ipc.md

@@ -0,0 +1,132 @@
+# IPC: message-passing channels
+
+Inter-process communication is the **backbone of a microkernel**. Once drivers and
+services run isolated in their own address spaces ([vision](../vision.md)), they can't
+just call each other — a request becomes a **message**. In a microkernel, whatever
+was a function call across a monolithic kernel is IPC, so it's a first-class
+concern, not an afterthought.
+
+There are two layers, built a milestone apart:
+
+- **`system/kernel/ipc.zig`** — a bounded blocking channel between *kernel threads*,
+  described below. The primitive, and where the blocking discipline was worked out.
+- **`system/kernel/ipc-synchronous.zig`** — synchronous call/reply between *processes*, across
+  address spaces. What user-space servers and drivers actually talk over. It's the
+  second half of this document.
+
+## The channel
+
+The first form is a **bounded blocking channel** (`system/kernel/ipc.zig`): a fixed-size
+ring buffer of messages with a producer/consumer rendezvous, built on the
+scheduler's [wait queues](../os-development/scheduling.md).
+
+`Channel(T, capacity)` is generic over the message type and buffer size. It holds a
+ring buffer, a count, and two wait queues:
+
+- **`send(msg)`** — if the channel is full, block on the *not-full* queue; otherwise
+  write the message, bump the count, and wake a waiting receiver.
+- **`receive()`** — if the channel is empty, block on the *not-empty* queue; otherwise
+  take a message, drop the count, and wake a waiting sender.
+
+Neither side busy-waits: a full channel parks the sender, an empty one parks the
+receiver, and each operation wakes the other side when it makes progress possible.
+
+Two details make it correct:
+
+- **Recheck in a loop.** A woken task re-tests the condition (`while (full) wait`)
+  rather than assuming the slot is still available — another waiter may have taken
+  it first. This is the standard guard against spurious or racing wakeups.
+- **One critical section.** `send`/`receive` run under the [big kernel
+  lock](../os-development/smp.md) (`sync.enter` / `sync.leave`), which disables interrupts on this
+  core *and* takes the kernel's one spinlock — since SMP, the interrupt flag alone
+  is not atomicity, because `cli` on one core does nothing to another. So checking
+  the condition and committing the block/enqueue happen atomically both with respect
+  to the timer preempting mid-operation and to the other side running on another
+  CPU. `waitLocked` / `wakeLocked` are the variants that assume the caller already
+  holds that critical section.
+
+## Verifying it
+
+The `ipc` test (see [testing.md](../testing.md)) runs a producer and a consumer passing
+**100 messages through a 4-slot channel**. The small buffer means the channel goes
+full and empty over and over, so both the blocking-send and blocking-receive paths are
+exercised heavily. The messages arrive intact and in order (their sum is the
+expected `5050`), and neither task busy-waits — they block and wake each other.
+
+## Endpoints: call/reply across address spaces
+
+A channel connects two kernel threads sharing one address space. Real servers are
+*processes*, so the payload has to cross an address-space boundary. That's
+`system/kernel/ipc-synchronous.zig`, and its shape is L4's: a synchronous **rendezvous** at an
+`Endpoint`, with the message copied directly from the sender's pages to the receiver's
+(`copyAcross` walks both sets of page tables through the physmap — no CR3 switch, no
+bounce buffer).
+
+Two syscalls carry it:
+
+- **`ipc_call(h, msg, reply)`** — copy `msg` to the server, block until it replies.
+- **`ipc_reply_wait(h, reply, recv)`** — reply to the client you're still holding (if
+  any), then block for the next request. One syscall, because a server's steady state
+  is *always* "finish the last one, wait for the next".
+
+An endpoint is reached by **handle** — a small integer index into the process's handle
+table (`Task.handles`), exactly like a file descriptor, and just as unforgeable. The
+bootstrap problem (how do you get the first handle?) is solved by a tiny name registry:
+a server calls `ipc_register(service_id, h)` under a well-known small integer, and a
+client calls `ipc_lookup(service_id)`.
+
+The server never learns the client's identity beyond a **badge**, delivered alongside
+the message: the caller's task id.
+
+### Interrupts are messages too
+
+`notifyFromIsr` posts an *asynchronous* notification to an endpoint — no payload, no
+reply owed — and wakes whoever is blocked in `reply_wait`. Its badge has the top bit
+set (`notify_badge_bit`), which is how a driver's single event loop distinguishes "a
+client wants something" from "the hardware wants something". Notifications sit in a
+small coalescing ring on the endpoint, so an interrupt taken while the driver was busy
+elsewhere is not lost.
+
+This is what makes a user-space driver possible at all, and it's the subject of
+[drivers.md](drivers.md).
+
+## What's next (partly done since)
+
+- **Priority inheritance** through IPC — still open: a high-priority client
+  blocked on a low-priority server suffers unbounded priority inversion.
+- **Handle transfer.** *Landed as cap-passing (M13)*: `ipc_call` and
+  `ipc_reply_wait` carry an optional capability alongside the bytes (`send_cap`),
+  copying an endpoint or shared-memory handle into the peer's table. First user:
+  [input](input.md) subscribers register by handing over their own endpoint, and
+  class drivers get a private channel to one device.
+- **Asynchronous / buffered send** for the cases where a rendezvous is the wrong
+  shape (logging, notifications between servers). *Landed as `ipc_send`* — a
+  non-blocking post to an endpoint's bounded payload queue, delivered through
+  `reply_wait` as a buffered message (badge bit `notify_message_bit`). Built for, and
+  first used by, the [input service](input.md)'s keyboard-event broadcast, where a
+  synchronous push would let one dead subscriber hang the fan-out. A full queue drops
+  the oldest (discrete messages, not a coalescing level like the notification ring).
+- **A bounded reply** — half landed. The copy is still 256 bytes
+  (`MESSAGE_MAXIMUM`) under the big kernel lock, but bulk transfer got its shared
+  pages: `shared_memory_create`/`map`/`physical`, the region handle delegated as
+  a capability (above). virtio-gpu's scanout surface is the first user
+  ([display-v2.md](display-v2.md)).
+
+## Lifecycle conventions over IPC (M17)
+
+Three conventions from [process-lifecycle.md](../os-development/process-lifecycle.md) ride the
+notification mechanism:
+
+- **Signals** arrive as notifications on the endpoint a process nominated with
+  `signal_bind` (`process.bindSignals`): badge = the signal bit plus the
+  coalesced pending mask (`process.signalsFrom` decodes). Statements,
+  never questions; no payload, no reply.
+- **One-shot timers** (`timer_bind`, `time.timerOnce`) land as a
+  timer-bit notification — the timed wait: a service arms a deadline and keeps
+  serving, instead of blocking in sleep.
+- **The universal ping**: a **zero-length request is the liveness probe**,
+  answered with a zero-length reply by the service harness itself
+  (`service.run`). No protocol's requests start at length zero, so the
+  encoding cannot collide, and a wedged service simply fails to answer — which
+  is the diagnosis. Deep health ("can I reach my hardware?") stays a per-service
+  protocol message.