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 <noreply@anthropic.com>
This commit is contained in:
rajames
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
4bdb210a99
commit
eda6577a53
@@ -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.
|
||||
|
||||
+53
-18
@@ -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.**
|
||||
|
||||
Reference in New Issue
Block a user