danos/docs/ipc.md

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), 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.

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), 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) 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.

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'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 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.