From eda6577a53df331a23e9fff4c8cf53fd57bca4c3 Mon Sep 17 00:00:00 2001 From: rajames Date: Wed, 7 Oct 2026 11:06:33 -0400 Subject: [PATCH] docs(v4.0.0): step 6a withdrawn -- drives that come and go are built as v3 has them Captain Bob, 2026-10-07. Rulings 6 and 8 of MESH.md 8.1 (a device identity in the block header, a returning device's old numbers, release by moving its blocks off, holes) were given without v3's design having been shown. MESH.md 8.7 sets v3's design beside them: a removable drive is a person's, known by its signature; WIREBIND; it joins at the tail and only the tail leaves; EJECT flushes to the drive and kills the user's VM. ENGINE.md steps 7 and 8 now say that is where it is built. Co-Authored-By: Claude Opus 5.5 --- docs/v4.0.0/ENGINE.md | 7 +++++ docs/v4.0.0/MESH.md | 71 ++++++++++++++++++++++++++++++++----------- 2 files changed, 60 insertions(+), 18 deletions(-) diff --git a/docs/v4.0.0/ENGINE.md b/docs/v4.0.0/ENGINE.md index a8074407..932d3eba 100644 --- a/docs/v4.0.0/ENGINE.md +++ b/docs/v4.0.0/ENGINE.md @@ -409,7 +409,14 @@ its logs. 6. **Hera as v3 has her.** `init.4th` runs on the node; v3's whole POST passes; v3's parity lines. 7. **The fleet.** Hestia and Artemis; message delivery; who runs next. + With Artemis: she is the owner of the disk, who says it may be + formatted, so that the disk is written as well as read (`MESH.md` step + 6); and a drive that arrives is registered by her, at the chain's tail. 8. **Identity and the prompt.** Zuse; `[zuse@Hera] ok>`. + With identity: drives that come and go, as v3 has them — the + home-blocks signature, `WIREBIND`, the user's VM born from the drive, + `EJECT`, and a surprise pull (`MESH.md` 8.7, which says why the storage + step that was to build them another way was withdrawn). Moving words from the assembled nucleus to `forth79.4th` goes on beside these, a group at a time, with POST after each. diff --git a/docs/v4.0.0/MESH.md b/docs/v4.0.0/MESH.md index ea2e8d87..c3605a22 100644 --- a/docs/v4.0.0/MESH.md +++ b/docs/v4.0.0/MESH.md @@ -298,20 +298,14 @@ in 8.6, so that it is not proposed again. It is v3's (`v3/include/block_subsystem.h`): the `STFR` version 2 header, the allocation map, the relocation table, and a card for every block (`blk_meta_t`). A disk v3 formatted reads in v4. -6. **Plus an identity.** *(step 6a)* Two fields are added in the header's - spare space, as v3 added its relocation and fence fields: the device's - identity, and the identity of the chain it belongs to. A v3 disk reads - zero there: not yet given one. With them a device is known when it - returns, wherever it is plugged in. +6. ~~Plus an identity: a device's and its chain's, in the header's spare + space.~~ **Withdrawn 2026-10-07**, 8.7. 7. **The mapper is the kernel's**: the device chain, the metadata, first-touch claim, ACL, migration and the Stadium touch stay in the kernel's block subsystem, which is v3's C code. -8. **A device leaves by being asked for.** *(step 6a)* Asked to release a - device, the mapper moves its blocks onto the devices that remain and - then says it may be pulled; if there is no room, the release is refused - with a message. A device pulled without asking leaves holes: its - logical numbers stay claimed and answer "no storage" until it returns, - is known by its identity, and its blocks are at the same numbers again. +8. ~~A device leaves by being asked for, its blocks moved onto the + others; one pulled without asking leaves holes; a returning device has + its old numbers.~~ **Withdrawn 2026-10-07**, 8.7. ### 8.2 What a node does *(step 6)* @@ -395,8 +389,9 @@ block number not to exist, and on the real chain it does. card's ACL and the Stadium touch need the node's identity (`V3-PARITY.md` 1d). Blocks are read and written through v3's subsystem with nobody's claim on them. Not as intended yet. -- **Chains of more than one device, identities, release and holes** are - step 6a. +- **Drives that come and go.** Step 6a, which was to build them, is + withdrawn (8.7). They are built as v3 has them, when v4 has identity + and the fleet (`ENGINE.md` steps 7 and 8). - **Cloud stores and real USB drives** wait for their drivers. ### 8.5 Ruled 2026-10-07, after the review of step 6 @@ -414,6 +409,46 @@ overwrite the node's code**, and **v3's way in full** — the block words are the kernel's, by number only, with the kernel keeping the record of the window and doing the copying. Both are built: 8.2 and 8.3. +### 8.7 Step 6a withdrawn 2026-10-07: drives that come and go + +Rulings 6 and 8 of 8.1 were given on 2026-10-06 in answer to questions put +without first saying how v3 does it. On 2026-10-07, shown v3's design, +Captain Bob withdrew step 6a as written. None of the four things it was to +build is v3's: + +| Ruled 2026-10-06 | v3 | +|---|---| +| A device identity and a chain identity in the block header | Identity is the signature and the keypair on the drive; the header has none | +| A returning device has its old block numbers | It joins at the tail again; its numbers depend on what else is attached | +| Release by asking: the mapper moves the device's blocks onto the others | `EJECT` flushes to the drive itself and kills the user's VM; nothing is moved off it | +| A surprise pull leaves holes that answer "no storage" | Only the tail can go; the user's VM is killed; there are no holes | + +**v3, as built** (`kernel/src/repl.c`, `v3/src/block_subsystem.c`, +`v3/src/word_source/block_words.c`; `FABRIC-2.md` Phase 8, D.3 and F.10): + +- A removable drive is a person's. It carries an identity, the home-blocks + signature and a keypair Zuse mints onto it. Plugged in, its signature is + checked and the user's VM is born from the drive (`WIREBIND`); the + user's blocks are on their own drive. +- The kernel polls USB; Hera asks Artemis to register the drive + (`HERA-BLK-ATTACH-REQ`), and Artemis adds it to the chain. +- A drive joins at the tail, and only the tail can leave + (`blk_subsys_detach_device`): taking one out of the middle would + renumber every device after it. +- Leaving by asking is `EJECT`, a word of Hera's alone: the user's blocks + are flushed to their drive and the user's VM is killed. +- A surprise pull kills the user's VM with no flush, and the kernel drops + the device and whatever was not written. +- Coming back, the drive is known by its signature and the user's VM is + born again; the data is there because it never left the drive. +- Every VM's block window is emptied when the chain changes. (v4 has this + already: `v4/system/blocks.c`.) + +v4 has none of what that rests on yet: Zuse and identities, `WIREBIND`, +user VMs born from a drive, Artemis, USB in the v4 boot. They are +`ENGINE.md` steps 7 and 8, and drives that come and go are built there, +as v3 has them. + ### 8.6 Withdrawn 2026-10-07 Each of these was ruled on 2026-10-06 or stood in this document, and each @@ -699,11 +734,11 @@ Each is tested, committed and pushed before the next. from `kmalloc` and is not cleared (`kernel_main.c`, where the chain is set up); only the ramdrive is. The v4 path clears its own. - **6a. Storage that changes while running.** Rulings 6 and 8 of - section 8.1: chains of several devices, the device and chain - identities, a device joining at the end and known when it returns, - release by asking, holes. Its acceptance is to be approved before it is - built. + **6a. Storage that changes while running.** **Withdrawn 2026-10-07** + (section 8.7): what it was to build is not how v3 does it. Drives that + come and go are built as v3 has them, with identity and the fleet + (`ENGINE.md` steps 7 and 8). + **6b. POST is the kernel's.** Ruled 2026-10-07 (section 9); design approved 2026-10-07, `NUCLEUS.md` 6.3 and section 7. **Done 2026-10-07.**