docs(rfc): propose RFC-0004 — inter-process communication - #9
Merged
Conversation
The second half of the kernel's core, and the paper "IPC is the product"
(§3) is argued on. It designs the mechanism, not any protocol spoken over
it, and it leans directly on the accepted capability model: endpoints are
RFC-0003 objects, and a message moves capabilities exactly as RFC-0003
moves them.
The load-bearing choices:
- Endpoints are named by capability. Send and receive rights on one
endpoint give a client/server split for free — a client cannot receive
on the server's endpoint because it was never handed READ. There is no
global endpoint registry the kernel arbitrates, which is what makes IPC
the enforcement surface rather than a hole beside it.
- Synchronous unbuffered rendezvous as the base primitive (L4). No kernel
message buffer: nothing to size, nothing to account, nothing to flood
(O-7), and no copy into and out of kernel storage — the multi-copy IPC
grave (Mach) avoided by construction. The cost — coupled scheduling and
deadlock risk — is stated and paid deliberately, with call and
non-blocking variants as the management.
- A register fast path (small messages, no allocation, no copy beyond
registers) and a bounded slow path (copy now; map/zero-copy once the
MMU exists, behind an ABI that hides the choice so IPC is buildable
before the MMU).
- Capability transfer in a message is atomic, TRANSFER-gated, fail-closed
— RFC-0003's move at runtime.
- call with single-use reply capabilities gives RPC without ambient
"who called me" state (O-4 preserved); bounded notifications give async
signalling with no payload and no flood.
Open questions named rather than solved: slow-path copy-vs-map (joins the
MMU RFC), multi-core rendezvous (the hardest — joins the scheduler),
timeouts, and the register budget (joins the syscall ABI RFC). The syscall
surface this implies (send/recv/call/reply/notify) is listed as semantics,
with the encoding left to the syscall RFC.
Verified: spelling and markdown gates clean across 54 files; every
O-number cited resolves against docs/threat-model.md; RFC-0003 reference
resolves.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
4 tasks
MatejGomboc
added a commit
that referenced
this pull request
Jul 30, 2026
The prior-art review's IPC findings, applied to RFC-0004 (still Proposed).
Four corrections, each tracing to a cited source in docs/research/0001:
- §5 no longer maps the sender's pages into the receiver during a message.
That is L4's "long IPC" — removed by seL4, NOVA and Fiasco.OC on
minimality grounds and, decisively for a verification-minded kernel,
because a page fault during the in-kernel copy introduces concurrency
that makes the kernel far harder to reason about. Bulk data now travels
through a shared Region capability established out of band, with IPC
carrying only a small descriptor; the in-message slow path is a bounded
small copy (seL4-IPC-buffer sized). This is the single most valuable
finding of the whole review: we had reinvented a legacy mistake.
- §5 fast path uses virtual message registers (seL4) rather than a
hard-committed physical x0-x7 set — the rigidity L4 engineered away —
and the ~100-cycle figure is reframed as software-logic overhead, not a
round-trip RPC (real one-way IPC is ~190-320 cycles on cited hardware).
The fast path is also stated to be capability-transfer-free by design:
a cap-carrying message leaves the register path.
- §4/§8 direct switch is priority-aware, and call is framed as
scheduling-context donation (migrating threads -> QNX priority
inheritance -> seL4 MCS). The review found the real synchronous-IPC
hazard is scheduling coupling, not deadlock; a client timer capability
cannot fix a server monopolising the caller's budget, only donation can.
This couples IPC to the scheduler RFC earlier than the draft implied.
- §8 reply is a first-class one-time object (seL4 MCS), destroyed on
caller death, with the withheld-reply denial (Shapiro 2003) named and
answered by the userspace watchdog.
Folded into this PR rather than a separate one because merging main
(RFC-0004 landed via PR #9) already brought RFC-0004 onto this branch and
resolved the changelog here; a second PR would only re-conflict on the same
changelog region. The RFC keeps its Proposed status — these are revisions
to a proposal, and the maintainer's verdict on the corrected design is
still owed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The kernel core's second half, and the paper "IPC is the product" (§3) is argued on. Designs the mechanism — endpoints, rendezvous, the register fast path, capability transfer — not any protocol over it. Leans on accepted RFC-0003: endpoints are capability objects, messages move capabilities.
The load-bearing choices:
call+ single-use reply capabilities — RPC without ambient "who called me" state (O-4 preserved). Bounded notifications — async signalling, no payload, no flood.Which pillar?
Kernel doctrine directly, pillar 2 by consequence — IPC is the capability system in motion. Depends on RFC-0003.
For your review, specifically
callsemantics + bounded notifications as the only async primitive ("want data? send a message").unsaferegisterunsafeblocks: None — paper only.Checklist
docs/threat-model.md; RFC-0003 reference resolvesdocs/CHANGELOG.mdupdated🤖 Generated with Claude Code