From f6b3ec54f44bf4b51fbcfbe19755b43439819204 Mon Sep 17 00:00:00 2001 From: rajames Date: Mon, 5 Oct 2026 17:05:00 -0400 Subject: [PATCH] docs(v4.0.0): the Stadium as the frame; blocks -- a v4 node asks by number Records that compudynamics is the kernel's Stadium (words, VMs, blocks, messages and ACLs all patrons of one engine), v3's block subsystem as built, and the ruling of 2026-10-05: a v4 node only asks for a block by number; ownership, ACL, physics and devices stay on the kernel's side under the VM's identity. Co-Authored-By: Claude Opus 5.5 --- docs/v4.0.0/V3-PARITY.md | 54 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) diff --git a/docs/v4.0.0/V3-PARITY.md b/docs/v4.0.0/V3-PARITY.md index 4e1bb5b4..6e71b81e 100644 --- a/docs/v4.0.0/V3-PARITY.md +++ b/docs/v4.0.0/V3-PARITY.md @@ -133,6 +133,60 @@ not this step. node prints. That is a work-around for the node owning what the kernel owns, and it goes when the engine takes the VM's place. +## 1c. The frame: the Stadium + +`FABRIC-2.md` section B: "words are stadium patrons, VMs are patrons, +blocks are patrons, messages are stadium patrons, all should be operated on +by THE SAME ENGINE." + +- A patron is one 64-byte cell of nine wires: identity, heat, TTL, pin, + link, behaviour, mass, payload, contains + (`kernel/include/starkernel/vm/stadium.h`). +- Heat is a conserved share of 1.0; K is that conservation. +- The behaviour is what happens when a patron leaves: words and VMs `COOL`, + blocks `MIGRATE`, messages `DELIVER`, ACLs `EXPIRE`. +- A cell never holds the thing itself, only its identity and heat. A word's + code stays in the dictionary; a block's bytes stay in the block + subsystem. + +Compudynamics is therefore the kernel's Stadium, not something inside the +VM engine. The engine's part is to report what it executes: in v3, +`stadium_word_dispatch(vm, word_id, tick)` from the inner loop. + +**Reading of the opcode ruling (section 2.7) in this frame, stated to +Captain Bob 2026-10-05 and not corrected:** on v4 that report carries an +opcode, and a VM's word patrons become its 32 opcode patrons. + +## 1d. Blocks (discussed and ruled 2026-10-05) + +**v3, as built:** + +- One block address space in kernel C (`v3/src/block_subsystem.c`): fast + RAM at 0 to 2047, the ramdrive, Artemis's virtio disk, USB drives, + chained. +- Every block has metadata (`blk_meta_t`): the owner's fingerprint, + `acl_allow`, `acl_ttl`, a write count, chain links. +- Blocks are patrons: `BLOCK`, `BUFFER` and `UPDATE` call + `stadium_block_dispatch` with the LBN; heat drives migration and wear + levelling (`kernel/src/vm/stadium_blocks.c`). +- Artemis is the Tripod leg that owns persistent storage. +- Identity lives there: a keypair Zuse mints onto a thumbdrive; its + fingerprint is stamped on every block it claims at first touch, behind + the home-blocks fence; the disk's genesis signature is how the kernel + knows Artemis's disk. + +A v3 VM's block words ask the kernel's block subsystem for a block and get +a buffer back. Ownership, ACL, physics and devices are the kernel's. + +**Ruling (Captain Bob, "yes"):** a v4 node only ever asks for a block by +number. Everything about who may have it is decided on the kernel's side, +under the VM's identity. The device chain, metadata, first-touch claim, +ACL, migration and the Stadium touch stay where they are. + +**What this says about the lone-node boot.** It gives the node a bare RAM +array behind its four block registers (D-19), which skips the address +space, the metadata, the owner, the ACL and the Stadium. + ## 2. Row 3: physics and per-word heat ### 2.1 What v3 does