FABRIC-3.md: scope WIREBIND (breadcrumb) and RUNCAP, add missing graph edges
WIREBIND traced against live capsule_birth_baby()/dispatch_init_forth() and found to have no real mechanism behind it yet -- depends on CERTVERIFY (identity-authentication) and a new RUNCAP mechanism for per-identity VM content, neither shown in the §E graph before now. Followed the thread into RUNCAP: capsule_birth_baby() is already generic, so RUNCAP needs only a heap-built single-entry capsule directory, not new birth machinery. Repurposes homeblocks_sig_t's now-dead blockmap_offset/blockmap_devblocks fields (per BMAPFMT, §F.4) to point at the identity's init source instead. Also captures a user-pool scope clarification: a thumbdrive is a user's pool by default, uncontested; FIRSTTOUCH's claim logic applies only to system-device extension.
This commit is contained in:
Robert Allan James
+99
-4
@@ -126,14 +126,19 @@ decisions get added here, not to `FABRIC-2.md`. Follow the same discipline `FABR
|
||||
### From FABRIC-2.md §X, Milestone 3 — Block subsystem extensions
|
||||
|
||||
- [ ] Implement the CA-signed-cert verification path (Milestone 6 dependency — the cert chain
|
||||
validator doesn't exist yet either).
|
||||
validator doesn't exist yet either). **Now confirmed a hard prerequisite of `WIREBIND` too
|
||||
(`FABRIC-3.md` §F.5), not just an M3 item in isolation.**
|
||||
|
||||
- [ ] Implement the first-touch allocation function: given a verified identity pubkey and a
|
||||
requested block count, either read an existing range from the drive's map or claim a new
|
||||
one at `g.total_user_lbn` and write it back. *(Single-block relocation itself — the
|
||||
mechanism this would allocate ranges for — is done: `blk_subsys_relocate_block()`/
|
||||
`RELOCATE-BLOCK`, `FABRIC-2.md`, commit `36d832f`. This item is about the identity→range
|
||||
allocation that decides what to relocate blocks* into*, still unbuilt.)*
|
||||
allocation that decides what to relocate blocks* into*, still unbuilt.)* **Scope clarified
|
||||
2026-08-27 (`FABRIC-3.md` §F.6, decision 3): a user's pool is their entire thumbdrive by
|
||||
default (never contested) plus any system-resident device blocks they additionally claim,
|
||||
first-come-first-served — this function only governs that second, system-side extension,
|
||||
not the drive itself.**
|
||||
|
||||
- [x] **SCOPED 2026-08-27 (FABRIC-3.md §F.4).** Design the on-drive block-map format (Section
|
||||
U item 4). Resolved as: no separate table — repurpose the existing, fully-wired-but-
|
||||
@@ -668,7 +673,10 @@ decisions get added here, not to `FABRIC-2.md`. Follow the same discipline `FABR
|
||||
|
||||
- [ ] Wire drive insertion (Milestone 2e's hotplug signal, post-identity-authentication) to a
|
||||
call into `capsule_birth_baby()` (confirmed a real, callable, on-demand birth path already)
|
||||
to spin up or re-attach that identity's VM.
|
||||
to spin up or re-attach that identity's VM. **Traced 2026-08-27 (`FABRIC-3.md` §F.5): this
|
||||
has no mechanism behind it yet — depends on both `CERTVERIFY` (identity-authentication) and
|
||||
a new `RUNCAP` mechanism (§F.6, scoped) for per-identity VM content, since
|
||||
`capsule_birth_baby()` today only births fixed, build-time-baked capsules.**
|
||||
|
||||
- [ ] Implement the actual attach/bind step — extending `sk_repl_set_active_vm()` (confirmed
|
||||
to exist, currently an unguarded raw pointer-set) with the key-match check from above, so a
|
||||
@@ -1320,7 +1328,11 @@ can't"):**
|
||||
- **How does thumbdrive content actually become a capsule at runtime?** `mkcapsule` only
|
||||
ever builds capsules at build time, baked into `capsule_generated.c` — nothing today
|
||||
constructs a capsule from data read off a live-attached device. This is new mechanism, not
|
||||
a variation on anything that exists.
|
||||
a variation on anything that exists. **SCOPED 2026-08-27, `FABRIC-3.md` §F.6**: no new
|
||||
birth machinery needed — `capsule_birth_baby()` is already generic; construct a
|
||||
self-contained heap-allocated single-entry directory (mirroring `kernel_main.c`'s own
|
||||
heap-copy of the compile-time directory) and feed it straight in. Source-location-on-drive
|
||||
and read-path details still open.
|
||||
- **Exact ACL "bumps and holes" comparison semantics.** Which specific ACL fields, compared
|
||||
how, constitute a console-to-VM match? Direction is settled (reuse ACL), the actual
|
||||
comparison logic is not designed.
|
||||
@@ -1438,6 +1450,8 @@ graph TD
|
||||
RUNCAP --> MINT
|
||||
|
||||
HOTPLUG --> WIREBIND
|
||||
CERTVERIFY -->|"post-identity-authentication" per M5 wording, SCOPED 2026-08-27 §F.5| WIREBIND
|
||||
RUNCAP -->|no per-identity VM content until this exists, SCOPED 2026-08-27 §F.5| WIREBIND
|
||||
ACLKEY --> BINDSTEP
|
||||
WIREBIND --> BINDSTEP
|
||||
BINDSTEP --> DETACH
|
||||
@@ -1483,6 +1497,11 @@ finished). Dashed arrows = softer "gates/informs" relationships.
|
||||
a parallel track.
|
||||
- **Only `SSDSCOPE`, `ROUNDTRIP`, `POLYBLOCK`, and `PROMPTBUG` are genuinely standalone** —
|
||||
everything else in the pile connects to at least one other node.
|
||||
- **`WIREBIND` was missing two real incoming edges** (found scoping it, §F.5): `CERTVERIFY`
|
||||
and `RUNCAP` both gate it, not just `HOTPLUG`. Without a verified identity there's nothing
|
||||
to bind to, and without `RUNCAP` there's no per-identity VM content to birth — today's
|
||||
`capsule_birth_baby()` only runs fixed, build-time-baked capsules by name, so "spin up that
|
||||
identity's VM" had no real mechanism behind it at all until this pass traced it.
|
||||
|
||||
**Not yet done:** an ordered plan (which node to attack first, given the graph). Per Captain
|
||||
Bob's own framing, that's the next pass — "start asking and answering questions iteratively
|
||||
@@ -1652,6 +1671,82 @@ or stay C-only like `zuse_cert_seed`'s "no FORTH access" precedent; the actual r
|
||||
edit to `block_subsystem.h`/`.c` itself (this pass produced the field design, not the code
|
||||
change).
|
||||
|
||||
### F.5 — `WIREBIND` (breadcrumb only — followed into `RUNCAP` instead, 2026-08-27)
|
||||
|
||||
Traced against the live code before asking anything: `capsule_birth_baby()`
|
||||
(`capsule_birth.c:473-614`) only ever births a fixed, build-time-baked `(p)` capsule looked up
|
||||
by name — `BIRTH`'s own mapping is literally `S" Artemis" → "artemis:init.4th"`
|
||||
(`mama_forth_words.c:216`). The PERSONALITY stage — where a baby would load *its own*
|
||||
per-identity content — is a confirmed no-op today: `dispatch_init_forth(new_vm)`
|
||||
(`capsule_birth.c:605`) does nothing, with its own comment stating "per-VM block storage is
|
||||
M9 scope; no-op until then."
|
||||
|
||||
**Finding: the M5 punch-list wording — "spin up or re-attach *that identity's VM*" — has no
|
||||
mechanism behind it yet.** Two real prerequisites were missing from the §E graph and are now
|
||||
added:
|
||||
- **`CERTVERIFY`** — M5's own wording calls this step "post-identity-authentication"; there's
|
||||
nothing to bind an identity to without a verified identity first. **Decision: required, not
|
||||
optional** — matches the literal M5 wording and avoids birthing VMs for unauthenticated
|
||||
drives before any lock/key concept (`ACLKEY`/`BINDSTEP`) exists to protect them.
|
||||
- **`RUNCAP`** — without it, "that identity's VM" can only ever mean the one generic,
|
||||
same-for-everyone capsule that happens to exist at build time. Real per-identity content is
|
||||
blocked on `RUNCAP` (or M9's per-VM block storage, a larger and further-out mechanism).
|
||||
|
||||
**Working assumption recorded for whenever this node is actually scoped:** a `WIREBIND`-
|
||||
triggered birth always creates a fresh VM (matches `capsule_birth_baby()`'s existing shape).
|
||||
Recognizing a *returning* identity and re-attaching to a prior VM/session is `ROUNDTRIP`'s
|
||||
question, not `WIREBIND`'s — deliberately not folded in here.
|
||||
|
||||
**Not scoped further — by design.** Rather than decide `WIREBIND`'s generic-capsule shape in
|
||||
the abstract, the pass followed the real blocker down into `RUNCAP` itself (§F.6). Revisit
|
||||
`WIREBIND` once `CERTVERIFY` and `RUNCAP` both exist.
|
||||
|
||||
### F.6 — `RUNCAP` (runtime capsule construction from thumbdrive content)
|
||||
|
||||
Traced against `capsule.h`/`capsule_birth.h` before assuming new birth machinery was needed.
|
||||
Two things, read directly from the code, changed the shape of this node:
|
||||
|
||||
1. **`capsule_birth_baby()` is already generic** — it takes `dir`/`descs`/`names`/`arena` as
|
||||
plain parameters; it is not wired to the compile-time `capsule_descriptors[]` global in any
|
||||
way. `mkcapsule` sets `.desc_capacity = capsule_count` always (`mkcapsule.c:955`) — despite
|
||||
`capsule.h`'s own comment calling this "fixed at compile time for **Phase A**" (implying
|
||||
headroom for a later phase), there is zero spare capacity reserved today, and no
|
||||
runtime-append mechanism exists into the baked-in directory. Not a blocker, though —
|
||||
2. **...because `RUNCAP` doesn't need to touch the baked-in directory at all.** It can
|
||||
construct its own self-contained, heap-allocated `CapsuleDirHeader` + one `CapsuleDesc` +
|
||||
one `CapsuleNameEntry` + a small arena — the exact same shape `kernel_main.c:729-750`
|
||||
already builds when it heap-copies the compile-time directory before Mama's own birth, just
|
||||
sized for a single entry instead of the whole set — fill the arena with raw FORTH source
|
||||
text read off the thumbdrive, and hand that straight to the existing, unmodified
|
||||
`capsule_birth_baby()`. No directory-merge logic, no changes to the birth path itself.
|
||||
|
||||
**Decisions made 2026-08-27:**
|
||||
|
||||
1. **Mechanism: heap-built single-entry capsule directory, not baked-in-directory extension.**
|
||||
Confirmed safe and minimal per the trace above.
|
||||
2. **Location of the source content on the drive.** `homeblocks_sig_t`'s `blockmap_offset`/
|
||||
`blockmap_devblocks` fields are already dead weight per `BMAPFMT`'s decision (§F.4) that
|
||||
ownership/ACL/state travel with `blk_meta_t`, not a centralized on-drive table. **Repurpose
|
||||
those two fields** (rename to `identity_src_offset`/`identity_src_devblocks`) to point at
|
||||
this identity's raw FORTH init/personality source instead of adding new fields — reuses
|
||||
already-reserved header space, keeps `homeblocks_sig_t`'s byte budget untouched. (Comment
|
||||
update in `homeblocks_sig.h` still owed when this is actually built, same as `F.4` already
|
||||
flagged.)
|
||||
3. **Scope of a user's pool — clarified 2026-08-27, corrects the framing this node started
|
||||
from:** a user's pool is **their entire thumbdrive by default**, plus any system-resident
|
||||
device blocks they additionally claim, first-come-first-served, plus the required metadata.
|
||||
The thumbdrive itself is never contested — it's already theirs, no claiming logic needed
|
||||
there. `FIRSTTOUCH`'s "claim a new range at `g.total_user_lbn`" logic (M3) applies only to
|
||||
the *system*-device extension, not the drive itself. This simplifies the personality-source
|
||||
question in decision 2 above: no allocation contention to resolve, just a pointer into the
|
||||
drive's own metadata partition.
|
||||
|
||||
**Not yet scoped (deferred within this node):** the exact read path (which forth-blocks within
|
||||
the metadata partition, how `identity_src_devblocks` bounds a variable-length FORTH source);
|
||||
whether the source is plain FORTH text authored once at mint time or something a user can edit
|
||||
and have re-read on next attach; the interaction with `CERTVERIFY` (does verification gate
|
||||
reading this content, or only gate the resulting birth).
|
||||
|
||||
### D.5 — Scope expansion (2026-08-27): identity is common to every VM, not just users
|
||||
|
||||
Surfaced while scoping `ACLKEY`, stated directly: *"the whole object is to deliver a
|
||||
|
||||
Reference in New Issue
Block a user