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
86 lines
3.9 KiB
Plaintext
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
|