admin/LithosAnanake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

starkernel: item 2.2 complete -- bound the VM registry

Browse Source 
Wires the birth-refusal check into capsule_birth_baby(): calls
vm_registry_live_count() (added in the prior WIP commit) between
capsule validation and vm_registry_alloc(), returning the new
CAPSULE_RUN_ERR_FLEET_FULL and logging via
capsule_parity_log_birth_failed() before any EMBRYO registry slot is
consumed.

Also fixes a gap in that WIP commit: STADIUM_MAX_VM_COUNT was only
ever defined via a Kconfig .config-driven -D flag, with no fallback
default the way every sibling knob in starforth_config.h has -- a
build with no .config present (this one) failed with the macro
undeclared. Added STARFORTH_CONFIG_STADIUM_MAX_VM_COUNT_DEFAULT (4,
matching Kconfig.kernel) following the existing HEARTBEAT_INFERENCE_FREQUENCY
pattern exactly.

All three architectures boot clean to ok> with dict_hash=0x3d4e1daf289da94f,
matching the item-0.10/2.1 baseline. FABRIC.md item 2.2 checked off.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Robert Allan James
2026-08-04 13:54:22 -04:00
co-authored by Claude Sonnet 5
parent 5572e5e429
commit b0416794de
10 changed files with 31338 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
FABRIC.md
+25 -1
View File
@@ -2556,7 +2556,7 @@ document and committing that amendment as its own item.*
> 5.1), and can only be meaningfully measured once Phase 4 restores a multi-VM fleet
> anyway, per the limitation just above.
- [ ] **2.2 — Bound the VM registry.**
- [x] **2.2 — Bound the VM registry.**
The registry is a `kmalloc`-backed unbounded list (`capsule_vm_physics.c:71-72`). Give it
the hard bound decided in 1.5.
*Done when:* the population is bounded, birth at the bound behaves as 1.5 specifies, and
@@ -2578,6 +2578,30 @@ document and committing that amendment as its own item.*
> Making conservation *more* falsifiable is a different and larger piece of work — fixing
> the truncation leak — and is recorded in §25.7 rather than folded in here.
> **DONE 2026-08-04.** `STADIUM_MAX_VM_COUNT` Kconfig symbol (default 4, per item 1.5),
> wired through `Makefile.starkernel` and given the missing `starforth_config.h` fallback
> default (`STARFORTH_CONFIG_STADIUM_MAX_VM_COUNT_DEFAULT`) that the earlier WIP commit
> omitted — without it the macro was only ever defined when a Kconfig `.config` was active,
> and this build has none, so the first compile attempt failed with `STADIUM_MAX_VM_COUNT`
> undeclared. `vm_registry_live_count()` (added in the prior WIP commit, counts only
> `VM_STATE_LIVE` nodes) is now called in `capsule_birth_baby()`
> (`src/starkernel/capsule/capsule_birth.c`), between capsule validation and
> `vm_registry_alloc()`, so a full fleet is refused — returning the new
> `CAPSULE_RUN_ERR_FLEET_FULL` and logging via `capsule_parity_log_birth_failed()` with
> `vm_id=0` (no VM is allocated on this path) — before any EMBRYO registry slot is
> consumed.
>
> **Regression: clean.** All three architectures boot to `ok>` with identical
> `dict_hash=0x3d4e1daf289da94f`, matching the item-0.10/2.1 baseline: amd64
> (`logs/20260804-134914`), aarch64 (`logs/20260804-134957`), riscv64
> (`logs/20260804-135102`).
>
> **Honest limitation.** With Tripod pruned to Hera alone (item 0.1), the fleet never
> reaches `STADIUM_MAX_VM_COUNT` during boot, so this run exercises the bound-check code
> path only in the trivially-not-full case — the actual refusal branch is unexercised until
> Phase 4 restores a multi-VM fleet. Same caveat item 2.1 already recorded for the same
> reason.
---
## 25.4 Phase 3 — Stadium core