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

Register Hestia for switch signals -- FABRIC-3.6.md task 1.5

Browse Source 
Added a fourth capsule_vm_find_by_name_nocase("Hestia", ...) +
sk_vm_switch_signal_register(...) block in src/starkernel/kernel_main.c,
same shape as the existing Hermes/Artemis blocks, placed after all four
fleet members are confirmed born -- the existing comment on this block
already states why: no critical-section protection during setup, so
registering earlier risks the signal firing mid-birth.

Three-arch boot clean: amd64/aarch64/riscv64 all reach [zuse@Hera] ok>,
zero UNKNOWN WORD, hashes identical to task 1.4's baseline (this is
pure C runtime state, doesn't touch any FORTH dictionary). No compiler
warnings.

Took FABRIC-3.5.md SXXXV.0's "invisible by default" warning literally
rather than trusting a clean boot log alone: SXXVIII.2's own recorded
switch-storm signature is "QEMU pinned near 100% CPU, serial log frozen
solid," not an error message. Confirmed normal wall-clock boot time on
all three (~30s) and, since TCG itself always shows ~100% CPU
regardless of guest workload, watched each serial log's line count at
the idle prompt for 5-10s and confirmed it stopped growing rather than
flooding or silently stalling.

Authorized by Captain Bob ("yes").

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Robert Allan James
2026-09-19 17:07:19 -04:00
co-authored by Claude Sonnet 5
parent 10e2d654e5
commit 487769e18a
9 changed files with 27607 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
FABRIC-3.6.md
+19 -1
View File
@@ -359,8 +359,26 @@ Hestia; headless policy intact.
passing, not a regression: Hestia's birth log shows the same `( Unterminated comment`
HADES warning Artemis's own birth has shown since task 0.0's very first baseline — a
pre-existing quirk, not something this task introduced.
- [ ] **1.5** — Register Hestia for switch signals (the `:1007` pattern). *Check:* boot clean;
- [x] **1.5** — Register Hestia for switch signals (the `:1007` pattern). *Check:* boot clean;
**no switch storm** (§XXVIII.2's shape — and note it is invisible by default, §XXXV.0).
2026-09-19 · `logs/20260919-170232/amd64/`, `logs/20260919-170403/aarch64/`,
`logs/20260919-170537/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`,
hashes identical to task 1.4's baseline (switch-signal registration is pure C runtime
state, doesn't touch any FORTH dictionary). Added a fourth
`capsule_vm_find_by_name_nocase("Hestia", ...)` + `sk_vm_switch_signal_register(...)` block
in `src/starkernel/kernel_main.c`, same shape as the existing Hermes/Artemis blocks,
**after** all four fleet members are confirmed born (same "never register before birth is
confirmed" discipline the existing comment on this block already states).
**Took §XXXV.0's "invisible by default" warning literally rather than trusting a clean
boot log alone:** §XXVIII.2's own recorded storm signature is "QEMU pinned near 100% CPU,
serial log frozen solid" — not an error message, not `UNKNOWN WORD`. Named that signature
before running, then checked for it directly rather than just reading `ok>` and moving on:
confirmed each boot reached the prompt in normal wall-clock time (~30s, matching every
prior run in this document), and — since TCG itself always shows ~100% CPU regardless of
guest workload, so CPU alone proves nothing — watched the serial log's own line count at
the idle prompt for 5–10s on all three architectures and confirmed it **stopped growing**
(last real output, `StarForth CLI`/`ok>`, with nothing appended after) rather than flooding
or silently stalling mid-boot. No compiler warnings.
- [ ] **1.6** — Move `fabric.4th` from `init.4th` to `hestia/init.4th`. *Check:* Hera's dict
shrinks, Hestia's grows; cross-arch identity holds.
- [ ] **1.7** — Move `font.4th` likewise. *Check:* same.