starkernel: item 3.3 -- behaviour enumeration and dispatch

Punch list §25 item 3.3 complete.

StadiumBehaviour (stadium.h) enumerates exactly the four tags §18.3
already names -- MIGRATE, DELIVER, EXPIRE, COOL -- mapped from §17.1's
patron table: blocks->MIGRATE, messages->DELIVER, ACLs->EXPIRE, words
and VMs both->COOL. Nothing invented; the tag set and mapping were
already in the document.

stadium_dispatch(cell_index, behaviour) dispatches on the tag only,
never asks what kind of patron departed. Handlers are stubs -- the
real actions belong to subsystems not yet migrated onto the Stadium
(Phase 4). Nothing calls stadium_dispatch() yet; item 3.5 is its first
consumer.

The switch is exhaustive with no default case, making §13's "closed
enumeration, fixed at build time" a compiler-enforced property under
this project's -Wall -Werror rather than just prose. Verified live:
temporarily deleted the COOL case, rebuild failed with
error: enumeration value 'STADIUM_BEHAVIOUR_COOL' not handled in
switch [-Werror=switch], restored it, confirmed clean again.

The header's behaviour field stays uint8_t, not the enum type itself,
since C does not guarantee an enum's underlying type and that field's
offset is load-bearing for item 3.1's validated 64-byte layout.

Verified: three-architecture boot (amd64, aarch64, riscv64), all
reaching ok> with identical dict_hash=0x3d4e1daf289da94f matching the
item-3.2 baseline.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Robert Allan James
2026-08-04 17:06:14 -04:00
co-authored by Claude Sonnet 5
parent eb0fd4fffa
commit 378d688898
10 changed files with 31408 additions and 3 deletions
+33 -1
View File
@@ -2739,8 +2739,40 @@ document and committing that amendment as its own item.*
> **Explicitly not built here, reported per §25.0 rule 3:** per-VM free lists (§22.3, "each
> VM holds its own free-list head index into the global array") — those get granted when
> Hera assigns a VM its quota, which is not this item's scope.
- [ ] **3.3 — Behaviour enumeration and dispatch.** Closed tag set fixed at build time.
- [x] **3.3 — Behaviour enumeration and dispatch.** Closed tag set fixed at build time.
Enumerate behaviours, never patron kinds. *Refs:* §13, §18.3.
> **DONE 2026-08-04.** `StadiumBehaviour` (`stadium.h`) enumerates exactly the four tags
> §18.3 already names — `MIGRATE`, `DELIVER`, `EXPIRE`, `COOL` — mapped from §17.1's
> patron table: blocks→MIGRATE, messages→DELIVER, ACLs→EXPIRE, words and VMs both→COOL
> (§18.3 explicitly: "a VM's behaviour tag is COOL, the same tag a word carries"). Nothing
> invented — the tag set and mapping were already in the document.
>
> `stadium_dispatch(cell_index, behaviour)` (`stadium.c`) dispatches on the tag only —
> never asks what kind of patron departed, per §3/§18.3. Handlers are stubs (console log
> only): the real migrate/deliver/expire/cool actions belong to subsystems not yet
> migrated onto the Stadium (Phase 4, §25.5). Nothing calls `stadium_dispatch()` yet
> either — item 3.5 is its first consumer.
>
> **The closedness requirement is now a compiler-enforced property, not just prose:** the
> switch in `stadium_dispatch()` is exhaustive with no `default` case. Verified this is
> real, not decorative — temporarily deleted the `COOL` case, rebuilt, got
> `error: enumeration value 'STADIUM_BEHAVIOUR_COOL' not handled in switch
> [-Werror=switch]`, restored it, confirmed clean again. Under this project's
> `-Wall -Werror`, a fifth behaviour tag added without updating dispatch is now a build
> failure, not a silent gap — the strongest available reading of §13's "closed enumeration,
> fixed at build time."
>
> The header's `behaviour` field stays `uint8_t`, not the enum type itself: C does not
> guarantee an enum's underlying type, and that field's offset is load-bearing for the
> exact 64-byte layout item 3.1 validated. Documented as holding `StadiumBehaviour` values
> cast to `uint8_t`. No new Kconfig symbol — this is a closed code set, not a tunable
> number.
>
> **Regression: clean.** All three architectures boot to `ok>` with identical
> `dict_hash=0x3d4e1daf289da94f`, matching the item-3.2 baseline — amd64
> (`logs/20260804-170226`), aarch64 (`logs/20260804-170309`), riscv64
> (`logs/20260804-170407`).
- [ ] **3.4 — Density ranking.** Heat ÷ mass, read not computed. *Refs:* §19.2, §19.3.
- [ ] **3.5 — Admission and eviction.** Admit if denser than the least dense resident.
*Refs:* §19.3.