docs: teardown-unification design proposal - #496
Merged
Conversation
This was referenced Aug 5, 2026
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
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.
PROPOSAL — awaiting operator ratification
This is a design-only proposal. No implementation has been performed and no runtime evidence is
claimed anywhere in the document — every build/QEMU/Parallels statement is a gate to be run, not a
result already obtained. It publishes the synthesized teardown-unification design for the operator to
ratify, adjust, or reject before any code lands.
Thesis
Senders mark; victims exit themselves; reapers own corpses; retirement is proof-gated.
No path ever tears down a process that is executing somewhere else. A killer's entire job is to record
an intent and kick a CPU. The victim performs its own teardown, on its own stack, in ordinary kernel
context, with no lock held for anything slow. Physical release happens only after a fenced two-epoch
grace and a positive proof that no CPU, no scheduler cache, and no live row still names the resource.
The design was produced by a three-way panel (design A: minimal-incremental / Opus; design B:
Linux-fidelity / Codex Sol; design C: invariant-first / Codex Sol) plus two adversarial judge passes,
archived for the record under
docs/planning/teardown-unification/panel/design-{A,B,C}.md. The ruling:B wins the architecture, A wins the phase plan, C wins the proof machinery — B's Linux-fidelity
state machine, re-sequenced under A's shippability discipline (spine first, every phase strictly
better, no dormant code), with C's proof machinery grafted wholesale and C's
ExitPendingstate(the mechanism that killed the earlier "grave" branch at r20) explicitly rejected.
Full design:
docs/planning/teardown-unification/DESIGN.mdPhase-by-phase implementation plan:
docs/planning/teardown-unification/PLAN.mdPhase list (13 phases / 13 PRs, each ≤~230 changed lines / ≤5 production files, each independently shippable)
do_exit_current, normal exit as first consumerterminatecallers)Open questions (operator decisions only — see DESIGN.md §7 for full detail)
EPERMon user-originated signals to init) vs. treatauthorized
SIGKILL(1)as deliberate shutdown; OQ-1b stop-the-world SMP broadcast, in this round or not.exit(2)= member scope,exit_group/SIGKILL/fatal signal/fatal fault = thread-group scope.kernel/src/syscall/time.rs's raw TTBR0 writer through the constrained helper.Scope
Spine: #491. Also addresses #464, #471. Acknowledges and does not foreclose #448, #492, #493.
Next step
Operator reviews DESIGN.md/PLAN.md, answers OQ-1 through OQ-9, and the phase-0 PR is opened against
this ratified plan.