# 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](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.
- **`recv()`** — 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`/`recv` run under `saveInterrupts` /
  `restoreInterrupts` (the composable form, see [scheduling.md](scheduling.md)), so
  checking the condition and committing the block/enqueue happen atomically with
  respect to the timer preempting mid-operation. `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-recv 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 (not done here)

- **Priority inheritance** through IPC, so a high-priority client blocked on a
  low-priority server doesn't suffer unbounded priority inversion.
- **Handle transfer.** A server can't hand a client a handle to a third endpoint, so
  every capability is either well-known (the registry) or inherited — there's no way
  to delegate one.
- **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.** `MSG_MAX` is 256 bytes and the copy runs under the big kernel
  lock; a bulk transfer wants shared pages, not a copy.

## Lifecycle conventions over IPC (M17)

Three conventions from [process-lifecycle.md](process-lifecycle.md) ride the
notification mechanism:

- **Signals** arrive as notifications on the endpoint a process nominated with
  `signal_bind` (`runtime.process.bindSignals`): badge = the signal bit plus the
  coalesced pending mask (`runtime.process.signalsFrom` decodes). Statements,
  never questions; no payload, no reply.
- **One-shot timers** (`timer_bind`, `runtime.system.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
  (`runtime.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.