docs(v4.0.0): storage -- step 6 done

MESH.md step 6 as built, what is not as intended yet, and step 6b for POST becoming the kernel's. README and V3-PARITY.md brought up to date. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 08:31:23 -04:00
parent 7c06bdfdb6
commit 6d90375da7
3 changed files with 83 additions and 12 deletions
@@ -358,9 +358,13 @@ v4 system has none to give. **Ruled 2026-10-06:** the argument is removed.
 ramdrive and the virtio disk — in place of the RAM array
 `kernel/src/v4/sk_v4.c` gives it today. (Approved.) Found 2026-10-06:
 `kernel_main.c` starts the v4 node (line 523) before it sets that chain up
-(lines 620 to 668), and the v4 node never returns, so under `STARFORTH_V4`
-the chain does not exist today. Step 6 has the kernel set it up before the
-node starts.
+(lines 620 to 668), and the v4 node never returned, so under `STARFORTH_V4`
+the chain did not exist. As built: the node boots and is POSTed against
+POST's own block RAM, blocks 1 to 2047 and nothing above them, and the
+chain is set up after POST and before the prompt. That is v3's order
+(`sk_vm_bootstrap.c` gives POST `sk_post_blk_ram`; `kernel_main.c` sets the
+chain up later), and POST's cases depend on it: several expect a high
+block number not to exist, and on the real chain it does.

 ### 8.4 Not in step 6

@@ -586,19 +590,65 @@ Each is tested, committed and pushed before the next.
     `BYE`, and nothing it asks is honoured, as ruled.
   - The suite now takes about four minutes, eight under the sanitizers:
     five POSTs.
+   - **Changed at step 6 (2026-10-07):** `BIRTH` no longer sends POST, and
+     a born node is not POSTed. What is said of POST on the outer nodes
+     above is step 5 as it was built.
 6. **Storage (section 8): every node asks the kernel for its blocks.**
-   Sections 8.2 and 8.3. Tests: a node reads and writes blocks by kernel
-   request, and what v3's own calls wrote reads back; in the unit of five,
-   one node writes a block and another reads it (acceptance 3); Hera no
-   longer sends POST to the nodes she births; POST 538 of 538 on Hera with
-   `blocks.v4` changed, at both widths and under the sanitizers;
-   `hosted-check`; the three bare-metal boots.
+   **Done 2026-10-07.** It was first built another way and brought back;
+   8.5 says what was withdrawn and why.
+   - *The requests* (`v4/include/v4/blocks.h`, `v4/system/blocks.c`). -1
+     reads a block and -2 writes one, `( n waddr -- status )`, for any
+     node, from the kernel's block subsystem. `v4/tests/test_blocks.c`: 22
+     checks at 64 bits, 21 at 32 — a block written and read, the fast RAM,
+     numbers that are no block, cells that are not in the node's memory,
+     and that what v3's own calls wrote is what the node reads.
+   - *The node* (`v4/capsule/blocks.v4`). `(DEVICE)` makes the request on
+     port 0. The four storage registers and `v4_node_storage_attach` are
+     gone from the engine. Error 17 is "Storage refused".
+     `v4/tests/test_host_quit.c`: its block cases unchanged, and a disk
+     that will not be written says so and empties the buffer.
+   - *v3* (`v3/src/block_subsystem.c`). `blk_subsys_init` takes no `VM`.
+     Nothing else of it is changed. Accepted on the v3 configuration, three
+     ISAs, `PARITY:M7.1a` hash `0x08873e0f44b7cb2a` as on 2026-10-03:
+     `logs/20261007-082647`, `-082752`, `-082938`.
+   - *The unit of five* (`v4/tests/test_host_unit.c`, 47 checks). Every
+     node has its kernel on port 0: it serves a node's blocks, and Hera's
+     requests for nodes from Hera alone. One node writes a block and the
+     other four read it; two nodes write ten blocks each at once and all
+     twenty reach the chain. Hera's `BIRTH` no longer sends POST
+     (`capsules/v4/hera.4th`): one POST tally is seen, Hera's.
+   - *The products.* Hosted: the chain's fast RAM, blocks 1 to 2047, as
+     hosted v3 has with no disk; `hosted-check` passes on three ISAs.
+     Bare metal: POST against its own block RAM, then the chain — fast
+     RAM, the ramdrive at 2048 to 3071, the virtio disk from 3072. Three
+     boots, POST 538 of 538, and typed at the prompt: block 2100 written
+     and read back, block 3072 read from the disk, a write to it refused,
+     a block that is not there. `logs/20261007-081603` (amd64), `-081839`
+     (aarch64), `-082226` (riscv64). The parity hashes are the same on the
+     three hosted and the three bare-metal systems.
+   - **Not as intended yet.**
+     - Who may have which block is not checked (8.4).
+     - On bare metal the virtio disk is read and not written. v3's
+       subsystem will not write a disk until its owner says it may be
+       formatted, and that owner is Artemis; so are the genesis signature
+       and Zuse's root key, which the v3 path does at the same place. v4
+       has neither Artemis nor Zuse yet.
+     - POST is still a capsule Hera loads; step 6b.
+     - The suite's unit test is still not run at 32 bits.
+   - **Seen and not changed.** On the v3 path the chain's fast RAM comes
+     from `kmalloc` and is not cleared (`kernel_main.c`, where the chain is
+     set up); only the ramdrive is. The v4 path does as v3 does.

   **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.
+   **6b. POST is the kernel's.** Ruled 2026-10-07 (section 9): the kernel
+   holds POST's cases and feeds them to Hera itself, with no POST words
+   loaded into her dictionary. Today they are a capsule she loads
+   (`NUCLEUS.md` section 6). Its design and acceptance are to be approved
+   before it is built.
 7. **A second unit; scaling while running; sleep, wake and kill by
   command.**
 8. **The hosted product is the five nodes**, on three ISAs: acceptance 1
@@ -26,7 +26,7 @@ the kernel's M0–M6 hardware milestones:
 | 3 | Physics live whenever a word executes: per-word heat, decay, rolling window, pipelining, L8 mode selector (61 mode changes during POST), heartbeat | Missing; see section 2 |
 | 4 | POST: 1050 tests, every module (FORTH-79, StarForth extensions, ACL, Mama, Q48, inference, physics freeze) | 550 cases, FORTH-79 Required Word Set only |
 | 5 | `PARITY:M7.1a` word count, here, latest, dictionary hash; `PARITY:OK`; `POST: PASSED` | Present, as `PARITY:V4_*` |
-| 6 | PCI; virtio-blk attached; Artemis genesis signature | Missing. Blocks are a RAM array |
+| 6 | PCI; virtio-blk attached; Artemis genesis signature | PCI and the disk attached, after POST (2026-10-07). No genesis signature; the disk is read and not written |
 | 7 | Mama init capsule `init.4th`: signature checked, executed, `PARITY:MAMA_INIT` | v4 loads its own two capsules the same way; not `init.4th` |
 | 8 | ACL: `BIRTH` and `CAPSULE-BIRTH` pinned strict | Missing. The ACL words are assembled but not loaded |
 | 9 | Heartbeat running; Stadium conservation checks; quota and kernel-Hermes self-tests | Missing |
@@ -187,6 +187,15 @@ ACL, migration and the Stadium touch stay where they are.
 array behind its four block registers (D-19), which skips the address
 space, the metadata, the owner, the ACL and the Stadium.

+**As of 2026-10-07** (`MESH.md` step 6): the registers and the RAM array
+are gone. A node's block words make a kernel request and
+`v4/system/blocks.c` serves it through v3's block subsystem, so the address
+space and the metadata are v3's. Still skipped: the owner and first-touch
+claim, the ACL, and the Stadium touch, which need the node's identity. A
+first build of that step had block requests passed from node to node and
+nodes with no storage; Captain Bob withdrew it as a divergence from this
+ruling (`MESH.md` 8.5).
+
 ## 1e. Messaging (discussed and ruled 2026-10-05)

 **v3, as built** (`FABRIC-3.5.md` sections III, XLIII, XLV;
@@ -126,11 +126,23 @@ no room for one more message lets it go and counts it in `(LOST)`.
 **Five nodes from nothing** (`MESH.md` step 5) is built and proven in the
 fabric under test: Hera asks whoever holds the fabric for a node
 (`v4/src/manage.c`: `NODE-BORN`, `NODE-WIRE` and the rest), sends it the
-nucleus through the port that joins them, then FORTH-79 and POST a line at
-a time, and joins four such nodes in a square round her
+nucleus through the port that joins them, then FORTH-79 a line at a
+time, and joins four such nodes in a square round her
 (`capsules/v4/hera.4th`: `BIRTH`, `UNIT`). `v4/tests/test_host_unit.c`.
 The two products are not yet this: they become the five nodes at steps 8
 and 9.
+A node she births is not POSTed: POST is the kernel's, once, on Hera.
+
+**Blocks** (`MESH.md` step 6). A node asks its kernel for a block, as a v3
+VM does: `BLOCK` and its family keep two buffers, and the word beneath them
+writes a request to port 0 with the block's number and the buffer's address
+on the stack (`v4/include/v4/blocks.h`). `v4/system/blocks.c` serves it from
+the kernel's block subsystem, which is v3's (`v3/src/block_subsystem.c`):
+one chain, the same blocks at the same numbers for every node. A hosted
+program has the chain's fast RAM, blocks 1 to 2047. On bare metal the chain
+is fast RAM, the ramdrive and the virtio disk; the disk is read and not yet
+written, because nothing in v4 gives its owner's word that it may be
+formatted. Who may have which block is not checked yet.

 **This is still the lone node.** On bare metal `kernel_main.c` starts it
 before the fleet tables, beside the kernel's own system and not in the VM's