diff --git a/FABRIC-3.md b/FABRIC-3.md index 1624c821..06d7e477 100644 --- a/FABRIC-3.md +++ b/FABRIC-3.md @@ -4810,8 +4810,129 @@ carefully rather than mechanically. This closes the four-part initiative opened in §XXXII: Stage A (`USE` fix, root-caused past the original symptom into the Hera-fault-scoping gap it exposed), Stage B (logging policy + -level-aware eviction), Stage C (triage), Stage D (fixes, this entry). §XXXII.2's human-vs- -unattended identity model remains open as Stage E, not started this pass -- its four design -questions (§XXXII.2) still need settling on paper before any code, per that section's own -"Stage E" plan. +level-aware eviction), Stage C (triage), Stage D (fixes, this entry). + +**Stage E update, 2026-09-16 -- also closed.** §XXXII.2's human-vs-unattended identity model +is fully settled and built: all four design questions ratified on paper (with two mid-course +corrections recorded plainly, not folded in silently -- the `drive_uuid` scratch-device +mechanism and the ACL-bit-vs-`ACL.4th` correction), then all four punch-list items +implemented and live-verified end to end (`MINT-SCRATCH`/`MINT-SCRATCH-EMIT`, +`UNATTENDED-BIRTH`, `CONSOLE-ATTACH`), closing with a real mint -> birth -> console-attach -> +relayed-command-executes-on-target proof, not just a structural argument. §XXXII as a whole is +now fully closed; the multiuser/multitasking DoE this unlocked is scoped separately as §XXXIII. + +## XXXIII. Multiuser/multitasking DoE -- design, no code yet (2026-09-16) + +**Origin.** With §XXXII closed (real concurrent VMs, real identity for both human and +unattended origins, real console attachment), Captain Bob asked whether we're positioned to +run a DoE that actually stresses the multiuser/multitasking capability itself, "a pretty big +experiment... long running multi-factor DoE that sort of puts the OS through its paces." This +section settles the design on paper before any code, per this project's own standing +discipline for every initiative this size. + +### XXXIII.1 -- Three corrections found before the design could be trusted + +**Console sessions are not a concurrency axis -- confirmed, not a defect.** `console_get_vm_ +name()` (`console.c`) is a single global `USE` mutates; `sk_repl_dispatch_line()`'s pairing +check (`repl.c:1241-1266`) reads it to decide which one `~user` VM the physical terminal +is currently relaying to. This is not an oversight -- `console.c` hardcodes one physical UART +(`NS16550_BASE`/COM1, a compile-time constant, not a discoverable device list) and every piece +of console state is a static module global, not a field on an instantiable type. One physical +terminal, one foreground session, by construction. Multitasking (many VMs alive and doing real +work concurrently) is real and unbounded by this; simultaneous *human* interaction from two +different physical seats is not something this kernel builds today. (Captain Bob's own +reaction to this finding is recorded separately, [[project_multiseat_console_idea.md]] in +memory -- a future multi-seat/telnet-ish/pty-multiplexer initiative, explicitly deferred +behind this DoE, not scoped here.) + +**The real, provable concurrency primitive is `VM-EXEC`.** `doe-campaign.4th`'s own +`THREE-VM-CAMPAIGN` already proves the pattern live: Hera dispatching work onto named child +VMs (`S" DOE-WORK" S" Hermes" VM-EXEC`) with no console involved at all. Checked live: +`mama_word_vm_exec()` resolves its target via `capsule_vm_find_by_name()` against the full VM +registry -- a plain `kmalloc`'d linked list with no hard size cap -- not against +`common:messaging.4th`'s 16-slot `VM-NAME-ADDRS`/`VM-NAME-LENS` routing table (that table is +scoped to `MSG-SEND` destination routing for the console-relay path specifically, and has +nothing to do with `VM-EXEC`). Concurrency level for this DoE is therefore bounded by kmalloc +heap headroom and sane trial runtime, not by any 16-VM ceiling. + +**No FORTH-reachable fine-grained clock exists.** `sf_monotonic_ns()` is used internally in C +(`dictionary_heat_diagnostic_words.c`, `physics_benchmark_words.c`) but nothing wraps it as a +callable word, and `capsule_mint.c`/`capsule_runcap.c` both say outright that no monotonic-ns +source exists anywhere in this codebase yet as a settled, general-purpose thing. **Latency is +dropped as a response variable for this campaign** rather than building a new timing primitive +under this scope; a future latency-focused campaign can add that word separately if wanted. + +**Found live, unresolved, noted rather than chased:** every acceptance boot this whole +session produced a `doe--.csv` even though `capsules/init.4th` itself never +calls `doe.4th`/`L8-DOE`, and `Makefile.starkernel`'s `KERNEL_ARGS` defaults to empty (the +`--doe` flag that does trigger it, `kernel_main.c:896-901`, is opt-in). Most likely a stale +`starforth.cfg` left on a boot image from an earlier session that `clean` doesn't touch -- +not root-caused, out of this section's scope. **Practical decision:** this new campaign is its +own explicitly-invoked driver capsule, independent of whatever is causing the existing L8 DoE +to run automatically; it does not attempt to disable or coordinate with that behavior. + +### XXXIII.2 -- Ratified design + +**Factor A -- concurrency level:** count of `VM-EXEC`-driven workload VMs alive at once. +Levels: **2 / 4 / 8**. + +**Factor B -- workload assignment:** which of the 10 existing workload capsules +(`workload-0.4th`..`workload-9.4th`) each concurrent VM runs. Levels: **uniform** (every VM +runs the same one, chosen per-trial) / **heterogeneous** (round-robin distinct assignment +across the live VMs). + +**Identity origin -- a fixed arm, not a crossed factor.** Crossing origin into the full +factorial would multiply the expensive axis (WIREBIND needs a real or emulated USB attach +event per identity) across every concurrency/workload cell. Instead: +- **Main block:** every concurrent VM is `UNATTENDED-BIRTH`'d (cheap, scales freely to the + full factorial above). +- **Fixed arm:** one smaller, separate block at a single concurrency level (4) and a single + workload mode (heterogeneous), with a mix of real WIREBIND-attached and unattended + identities, sized to what's actually practical to automate for USB attach at trial count + (punch-list item: confirm the automation mechanism, e.g. reusing the existing minted- + thumbdrive-image approach from the identity-verification campaigns, before fixing rep count). + +**Response variables (latency dropped, see XXXIII.1):** +- **Correctness proxy:** each trial VM completes its assigned workload run without setting + `vm->error` -- this measures "ran to completion under contention," not the workload's own + arithmetic correctness (the existing 10 workload capsules are physics-load generators, not + self-checking programs like the std79 exerciser was). Noted as a real limitation, not + silently assumed away. +- **Heat/CV stability per VM:** the same physics metric the existing single-VM L8 DoE already + trusts (`VM-PHYSICS-STATUS`, `INFER-VARIANCE@`-family words), now measured with real + concurrent neighbors present -- does contention perturb what a single VM's own physics + runtime reports about itself. +- **Completed-trials-per-interval:** a throughput proxy standing in for the dropped latency + variable -- how many of the N concurrent VMs finish their assigned run within the trial's + fixed iteration budget. + +**Trial mechanics (single boot per architecture, matching `doe.4th`'s own model -- not one +reboot per trial):** for each cell in a Fisher-Yates-shuffled run matrix (concurrency level × +workload mode × rep), `UNATTENDED-BIRTH` N fresh identities, assign workloads per the cell's +mode, drive each via `VM-EXEC` for a fixed iteration budget, collect the three response +variables per VM, then tear every trial VM down (`KILL`) before the next cell -- clean +isolation between trials, matching `doe.4th`'s own `PHYSICS-RESET-STATS`-per-run discipline. +CSV row per trial, same streaming-to-serial convention `doe.4th`'s `EMIT-ROW` already uses. + +**Reps and scale, proposed (not yet fixed -- punch-list item):** 3 concurrency levels × 2 +workload modes = 6 main-block cells; 10 reps/cell = 60 main-block trials. Fixed arm: 1 cell, +reps TBD pending the WIREBIND-automation punch-list item above. Total comfortably in the +"long-running, puts it through its paces" range Bob asked for without being unbuildable in one +pass -- open to widening (more concurrency levels, more reps) once the harness itself is +proven at this scale. + +### XXXIII.3 -- Punch list (design only -- no code authorized yet) + +- Confirm/build a practical WIREBIND-automation path for the fixed arm's mixed-origin block + (reuse existing minted-thumbdrive-image tooling from the identity-verification campaigns, or + scope a new one) and fix its rep count once the per-trial cost is known. +- Build the driver capsule (`multiuser-doe.4th` or similar): run-matrix generation/shuffle + (reuse `doe.4th`'s own `RUN-MATRIX`/`SHUFFLE-MATRIX` pattern), per-trial birth/assign/drive/ + measure/teardown, CSV emission. +- Decide the per-VM iteration budget (fixed count vs. fixed wall-clock-equivalent tick count, + given no monotonic clock is available -- likely a fixed heartbeat-tick count, matching how + the existing physics runtime already paces itself). +- Acceptance: 3-arch clean boot running the full campaign to completion, CSVs committed per + standing convention, at least one full pass reviewed for plausibility before calling the + harness itself proven.