diff --git a/FABRIC-3.5.md b/FABRIC-3.5.md index d820d87f..54da55cf 100644 --- a/FABRIC-3.5.md +++ b/FABRIC-3.5.md @@ -205,6 +205,11 @@ its own routing failure) not a special case but a direct corollary — see §VII ### III.3 — The by-name `VM-EXEC` dependency has to go somewhere. Open. +> **SUPERSEDED 2026-09-18 by §XIV.1/§XIV.2 — this question dissolved.** The three options below +> all assume the existing FORTH callers must be preserved. Captain Bob ruled the FORTH +> messaging layer legacy, so §XIII.1's inventory becomes input to a dead-FORTH cleanup rather +> than a migration constraint. Left in place, not rewritten. + §I.2's two Artemis call sites are the sharp edge. `S" ..." S" Hermes" VM-EXEC` requires a target VM with a dictionary. Three shapes are visible; **none is chosen here:** @@ -225,6 +230,11 @@ been run exhaustively for this document and must be, repo-wide, before scoping.* ### III.4 — The per-VM-arena question. Open, and the biggest unknown here. +> **RESOLVED 2026-09-18 by §XIV.1/§XIV.2.** Answered in the "full centralization" direction, +> but without the migration cost this section feared: with the FORTH legacy there is no live +> state to port. This was named the root dependency throughout §X; it is closed. Left in +> place, not rewritten. + Per §I.1 the arenas are per-VM dictionary allocations. If arbitration centralizes into the kernel, does `MSG-ARENA`/`CH-ARENA`/`MBR-ARENA` centralize with it, or does each VM keep its own outbox/inbox with only the *routing* centralized? These are very different amounts of @@ -260,6 +270,11 @@ arbitration) unchanged. Console takes the slot Hermes vacates. ### IV.2 — The "never renumbered" collision. Open, needs a ruling. +> **DISSOLVED 2026-09-18 by §XIV.1/§XIV.2 — via option 3 below, exactly as this section +> predicted.** The FORTH routing table is legacy, so the slot-numbering question has no +> subject. Option 3's own caveat ("settle §III.4 first") was the correct call. Left in place, +> not rewritten. + §I.3's comment commits to Hera/Hermes/Artemis at 0/1/2 and to identities at 3–10 *never* being renumbered. Hermes leaving index 1 forces a choice, and the existing comment forecloses the laziest option: @@ -566,10 +581,12 @@ There is no other test. ## XII. Explicitly not decided anywhere in this document -Collected so nothing here is mistaken for settled: §III.3, §III.4, §IV.2, §V.3 (all four), -§VI.3, §VI.4, §VII.2 (number and consumer), §VII.3, §VII.4, §VIII.3 (all three), §IX.3 (both), -and — added 2026-09-18 — §XIII.5's Console-singleton question (punch item 12), which gates -§IV entirely. §XIII.5's proposed resolution shape is **analysis, not a ruling.** +Collected so nothing here is mistaken for settled. **Updated 2026-09-18 after §XIV's rulings** +— §III.3, §III.4 and §IV.2 have left this list (resolved or dissolved; see §XIV.2). Still open: +§V.3 (all four), §VI.3, §VI.4, §VII.2 (number and consumer), §VII.3, §VII.4, §VIII.3 (all +three), §IX.3 (both), §XIII.5's Console-singleton question (punch item 12, gates §IV), +§XIV.4's message-durability trade (item 15), and §XIV.5's scheduler firewall (item 14). +The proposed resolution shapes in §XIII.5, §XIV.4 and §XIV.5 are **analysis, not rulings.** What **is** decided, all by Captain Bob on 2026-09-18 and recorded in §III.1, §IV.1, §V.1, §VI.1, §VII.1, §VII.2, §VIII.1 and §IX.1: Hermes goes into the kernel and becomes the arbiter @@ -766,3 +783,139 @@ Nothing found here dislodges §III.4 as the root dependency. Two adjustments: contents). Reported, not fixed. Items 3–11 unchanged and still open. + +--- + +## XIV. Two rulings that collapse the root dependency (Captain Bob, 2026-09-18) + +### XIV.1 — RULING: the existing FORTH messaging layer is legacy. Kernel Hermes is greenfield. + +**Captain Bob, 2026-09-18, verbatim:** "as far as Hermes the VM and Hermes the kernel +component, forget all the forth existing and call it legacy for now. We'll do a code cleanup +for all the dead FORTH anyway." + +So kernel-Hermes is **not** a migration of `capsules/common/messaging.4th`. It is a new C +implementation; the FORTH messaging layer becomes legacy on arrival and is retired by a +separate dead-FORTH cleanup pass. This reverses the framing §III.3 and §III.4 were built on — +both assumed the existing FORTH had to be carried across. + +### XIV.2 — What this collapses + +Four of this document's open questions dissolve rather than get answered: + +- **§III.4 (the root dependency) — RESOLVED by fiat, in the "full centralization" direction, + but without the migration cost that made it frightening.** The kernel owns message and + channel state; `messaging.4th`'s per-VM `CREATE`/`ALLOT` arenas are legacy, not something to + centralize. §III.4 feared a painful port of live FORTH state; there is no port. +- **§III.3 (the by-name `VM-EXEC` dependency) — dissolved.** The three-option framing + (kernel primitives / vestigial name / birth-time registration) was about preserving callers. + With the FORTH legacy, §XIII.1's 14-site inventory stops being a migration constraint and + becomes an input to the cleanup pass. **§XIII.1's inventory is still the right list — its + purpose changed, not its content.** +- **§IV.2 (routing-table slot numbering) — dissolved, exactly as §IV.2's own option 3 + predicted:** "the routing table stops being a FORTH array at all... in which case this + question dissolves into §III.4's arena question." It did. `VM-NAMES-INIT`'s 0/1/2 pinning and + the "never renumbered" commitment are legacy artifacts, not constraints on the new design. +- **§XI item 13 (the `MANIFEST.md` corrections) — absorbed.** Bob's "we'll do a code cleanup + for all the dead FORTH anyway" covers §XIII.2's findings. Still worth doing deliberately; + no longer a separate ask. + +**§XIII.1, §XIII.2 and §XIII.3 keep their value** — the C-side sites (§XIII.3) are *not* +legacy and remain real edit sites, and the dead-FORTH inventory now feeds the cleanup. + +### XIV.3 — RULING: Artemis is the persistence path. And it needs no layering inversion. + +**Captain Bob, 2026-09-18:** "For persistence though, use Artemis as much as possible. We're +good with that part for sure." Ratified. + +**A layering question this raises, traced 2026-09-18 and answered cleanly.** Artemis is a VM on +the Stadium floor; kernel-Hermes sits *below* the floor. "Persist via Artemis" reads at first +like an inversion — the kernel arbiter calling up into a floor VM. It is not, because storage +is already two layers, not one: + +- **The block subsystem is kernel/shared C, below the floor:** `src/block_subsystem.c`, + `src/blkio_*.c`, `src/starkernel/virtio/virtio_blk.c`. `capsule_loader.c:98-100` calls + `blk_subsys_init()` and `blk_subsys_add_raw_device()` directly, with no Artemis involved at + all. +- **Artemis is the storage *policy arbiter* on the floor:** it owns attach/registration + (`blk_subsys_attach_device()` via the `BLK-ATTACH` primitive — `repl.c:525-531` states it + outright, "Artemis's own domain now, not Hera's") and the on-disk Artemis format. + +So the ruling is satisfiable without inversion, by keeping the two straight: **floor-level and +fleet persistence goes through Artemis, its domain and its format; anything kernel-Hermes +itself needs uses the same block subsystem Artemis is built on — never a new one, and never by +messaging Artemis.** + +Worth recording that the kernel *already* calls up into Artemis by name today +(`repl.c:539-541`, `S" %llu HERA-BLK-ATTACH-REQ" S" Artemis" VM-EXEC`), with a comment +explaining it is a direct `VM-EXEC` rather than a real message because Hera can't use her own +`MSG-SEND` there. That precedent exists; this section is about not *depending* on it. + +### XIV.4 — The one real hazard in the persistence ruling, and the shape that avoids it + +**Kernel-Hermes must not depend on Artemis for the persistence it needs during its own +failure.** This is the same structural trap as §VIII: if Hermes must write something at death +and reaching Artemis requires routing, the dependency closes a circle on exactly the mechanism +that is broken. §VIII solved the *signalling* case with a semaphore; the persistence case +needs the same discipline rather than a second special case. + +**Recommended shape — analysis, not a ruling, Captain Bob's call: kernel-Hermes holds only +reconstructible state.** If the arbiter's routing state can be rebuilt from the live VM +registry (which `capsule_birth.c` already maintains as the authority on who exists), then: + +- Hermes has nothing that *must* be persisted, so the Artemis dependency never arises. +- §VII.4's "what does warm restart mean for Hermes" becomes trivial — rebuild from the + registry, no saved state to reconcile. +- Losing in-flight messages when the arbiter dies is consistent with §VII.1 step 3's "no + lingering, no partial states," and with §VIII's clean-shutdown window. + +This costs message durability across an arbiter death. **Flagged as the real trade**, and the +one to rule on: if in-flight messages must survive Hermes dying, Hermes needs durable state, +and that durable state cannot route through Artemis at death-time. + +### XIV.5 — Still open, and now more urgent, not less: the scheduler firewall + +Raised 2026-09-18 and **not yet ruled on**. Recorded here because §XIV.1 changes its timing. + +The fleet already has a scheduler: §XXVIII built timer-driven preemption, and `MSG-SEND` +(`messaging.4th` block 5021) already calls `SWITCH-MARK-WORK` → `sk_vm_switch_signal_mark_work()`, +setting `has_work` on the target's switch slot; `sk_vm_switch_signal_tick()` switches when +`readiness >= SK_SWITCH_READINESS_THRESHOLD` **and** `has_work`. **Message arrival is already +a scheduling input.** This directly contradicts `VM-PHYSICS-DYNAMIC-FLEET-DESIGN-20260705.md`'s +"Explicitly not wanted: a VM scheduler. Nothing gets built that decides whose turn it is to +execute" — a live tension in the project that predates this document and is not this +document's to resolve, but is this document's to not make worse. + +**Why §XIV.1 sharpens it.** Today that coupling runs FORTH `MSG-SEND` → C primitive → switch +slot. With the FORTH legacy, **kernel-Hermes becomes the caller of +`sk_vm_switch_signal_mark_work()` directly** — eligibility marking moves inside the arbiter. +That is the consolidation to guard against, and it happens by default unless the boundary is +stated up front. Greenfield is the right time to state it; retrofitting it later is how this +becomes a conventional scheduler by accident. + +**Proposed invariant, for ruling:** *kernel-Hermes carries, resolves and ACL-checks. It +publishes facts — "this VM has mail" — and never reads readiness, never orders traffic by +priority, and never decides turn order. `switch.c` remains the sole owner of "who runs next."* + +The argument for it is empirical and from this project's own history: §XXVIII.2 is a record of +switch-storms caused by **two sources of truth disagreeing** about who was running +(`vm_log_attributed_vm()` vs. the real trampoline state) — QEMU pinned near 100%, serial log +frozen solid. This codebase punishes duplicated authority with hangs. Two deciders would be +worse than one scheduler. + +### XIV.6 — Punch list after these rulings + +- ✅ **Item 3 (§III.4, the root) — RESOLVED** by §XIV.1. Kernel owns messaging; FORTH is legacy. +- ✅ **Item 4 (§III.3) — DISSOLVED** by §XIV.1; §XIII.1's inventory becomes cleanup input. +- ✅ **Item 5 (§IV.2) — DISSOLVED** by §XIV.1, as §IV.2 option 3 predicted. +- ✅ **Item 13 — ABSORBED** into the dead-FORTH cleanup pass. +- ⬜ **Item 14, NEW** — rule on §XIV.5's scheduler firewall invariant. **Raised, not ruled.** +- ⬜ **Item 15, NEW** — rule on §XIV.4: does message durability survive an arbiter death? If + yes, Hermes needs durable state that cannot route through Artemis at death-time. +- ⬜ Items 6, 7, 8, 9, 10, 11, 12 unchanged and still open. + +**Note the shape of what remains.** With the root dependency resolved, the surviving open +items are no longer about *mechanism* — they are about *authority*: who may birth (6, 7), who +decides a VM is dead (8, 11), who owns turn order (14), and what survives a death (15). That +is a better class of question to be left with, and §IX's "authority only ever flows down the +birth graph" is the principle most of them should be tested against.