Files
LithosAnanake/Kconfig.heartbeat
T
Robert Allan JamesandClaude Sonnet 5 9e81de3f43
Build / build-amd64-iso (push) Waiting to run
Build / build-aarch64-iso (push) Waiting to run
Build / build-riscv64-img (push) Waiting to run
xHCI/BOT driver: genuine multi-device support (FABRIC-3.md §VII)
Per-slot registry (xhci_msc_slot_t/dev->msc_slots, sized off the
controller's own reported max_slots) replaces the single-device scalar
fields the driver carried since Milestones 2e-2h. Boot-time port scan no
longer stops at the first connected device; a connect/disconnect that
arrives while the Command Ring is busy is now queued and drained instead
of dropped. blkio_usb.c and repl.c's own single-device state (device
descriptor buffers, blkio_dev_t, attach bookkeeping) became per-slot
registries the same way.

Live multi-device testing (not just compiling) surfaced a second, more
severe bug outside the original plan: transfer_purpose and next_action
were also single scalars shared across the whole controller. Two devices
enumerating concurrently could have one's completion silently overwrite
the other's still-outstanding one, permanently stalling it with no error.
Fixed by moving both per-slot and, critically, reading the Transfer Event
TRB's own real Slot ID field instead of trusting external bookkeeping.

Verified live, all three architectures, mandatory clean-qemu acceptance:
existing single-device path unchanged, and two devices attached
simultaneously (amd64) both progress independently through enumeration
without corrupting or stalling each other.

Also in this pass (implemented and verified in earlier turns this
session, committed together per direct instruction):
- Headless-until-login console policy: no prompt/banner until a real
  identity logs in via an attached thumbdrive (WIREBIND or Zuse, neither
  special), reusing EMERGENCY_CONSOLE_ENABLED as the debug/recovery
  escape hatch (now default-off).
- KILL/g_repl_active_vm dangling-pointer fix: killing the VM the console
  is currently USE'd onto now detaches back to Hera first, matching the
  existing EJECT/UNCLEAN precedent.

FABRIC-3.md §VII/§VIII carry full closure notes for all three.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4
2026-09-05 22:14:14 -04:00

86 lines
3.9 KiB
Plaintext

menu "Heartbeat / adaptive tick coordinator"
config HEARTBEAT_THREAD_ENABLED
bool "Run vm_tick() in a background thread (HEARTBEAT_THREAD_ENABLED)"
depends on STARFORTH_VARIANT_HOSTED
default y
help
y = OPTIMAL: vm_tick() runs in a dedicated background thread.
n = legacy inline tick, driven from the main interpreter loop.
Kernel-build resolution (Phase 4 of the Kconfig migration, the
phase's named verification target): `depends on
STARFORTH_VARIANT_HOSTED` above means this symbol is invisible for
a kernel-variant config -- CONFIG_HEARTBEAT_THREAD_ENABLED simply
never appears in a kernel .config/auto.conf, so
mk/Kconfig.mk's kconfig_bool bridge resolves it to 0 for kernel
builds without needing a special case. This is UI/model
correctness (menuconfig can't offer a choice LithosAnanke has no
way to honor -- there are no pthreads in a freestanding kernel),
not the sole enforcement mechanism: Makefile.starkernel additionally
keeps its own unconditional `VM_FEATURE_OVERRIDES +=
-DHEARTBEAT_THREAD_ENABLED=0` post-override exactly as it was
before this migration. Deliberately redundant with the `depends
on` above -- the Kconfig model documents *why* the kernel can't
offer this choice, the Makefile-level override *guarantees* the
kernel never ships with a threaded heartbeat even if the Kconfig
tree, a hand-edited auto.conf, or a future refactor ever
disagrees. Belt-and-suspenders on purpose: the failure mode this
guards against (a freestanding kernel image linking against
pthreads that don't exist) is silent-until-boot and expensive to
debug on real hardware, not the kind of thing to trust to a single
layer.
config HEARTBEAT_TICK_NS
int "Heartbeat thread wake period, nanoseconds (HEARTBEAT_TICK_NS)"
depends on HEARTBEAT_THREAD_ENABLED
default 10000
help
Background heartbeat thread wake frequency (default 10000ns = 1ms).
Only meaningful when HEARTBEAT_THREAD_ENABLED is on.
config HEARTBEAT_CHECK_FREQUENCY
int "Word-execution gate for a tick, executions (HEARTBEAT_CHECK_FREQUENCY)"
default 256
help
vm_tick() is gated by executed-word count, not just wall time --
this is how many word executions must occur between heartbeat
checks. This is also, note well, the same counter that makes
vm->heartbeat.tick_count a purely execution-driven virtual clock
(see docs/working/architecture/VM-FLEET-ATTRACTOR-DESIGN-20260705.md,
rev t) -- the value Loop #3 heat decay reads instead of real
nanoseconds, to keep dict_hash architecture-invariant.
config HEARTBEAT_WINDOW_TUNING_FREQUENCY
int "Rolling window width re-tune interval, ticks (HEARTBEAT_WINDOW_TUNING_FREQUENCY)"
default 1000
help
How many heartbeat ticks between Loop #5 (window width inference)
runs.
config HEARTBEAT_SLOPE_VALIDATION_FREQUENCY
int "Decay slope re-validation interval, ticks (HEARTBEAT_SLOPE_VALIDATION_FREQUENCY)"
default 5000
help
How many heartbeat ticks between Loop #6 (decay slope inference)
revalidation runs.
config EMERGENCY_CONSOLE_ENABLED
bool "Interactive fault handler / debug-escape REPL (EMERGENCY_CONSOLE_ENABLED)"
default n
help
Decided 2026-09-05: no console for the running system unless a
thumbdrive is present -- n (the new default) is the production/
high-security posture. When n: the kernel boots headless (no
banner, no prompt, no interactive surface at all) until a real
identity logs in via an attached thumbdrive (a regular user's
WIREBIND login or Zuse's own attach/genesis-mint -- neither is
special), and a runtime error halts the VM rather than handing
control back to an interactive console (no fallthrough surface).
Set to y only for debugging/recovery builds: the kernel shows its
interactive console immediately at boot regardless of any
thumbdrive, and REPL errors recover and continue instead of
halting. Applies to both the hosted VM and the kernel build.
endmenu