admin/LithosAnanake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

FABRIC-2.md: close section D §23.4 #2 -- settled by divergence, not by measurement

Browse Source 
Hermes v1's real message struct (init.4th blocks 4100/4105/4143) is 72 bytes with an out-of-line pointer+length payload, not the speculative 64-byte-cell/32-byte-inline-payload scheme from FABRIC.md §23.3. The design question is moot: the implementation went a different direction.
This commit is contained in:
Robert Allan James
2026-08-13 10:16:25 -04:00
parent a0033a2052
commit bdb85bc7c0
1 changed files with 18 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
FABRIC-2.md
+18 -1
View File
@@ -241,12 +241,29 @@ and recorded.
- [ ] **§17.4 — the framebuffer utility's internal heat/decay dynamics are undesigned.**
Explicitly "Open, deferred": not a Stadium patron, but what physics (if any) governs it
internally was never designed. Not blocking anything.
- [ ] **§23.4 #2 — cell-size validation against a real message shape.** "Check that a typical
- [x] **§23.4 #2 — cell-size validation against a real message shape.** "Check that a typical
message still fits in one cell" was never done — item 3.1's own done-note confirmed no
message-patron struct existed yet at the time. This is now checkable: item 4.2 built
Hermes's actual message/channel structures on the Stadium, so the 32-byte inline payload
can finally be validated against something real instead of a hypothetical.
> **SETTLED 2026-08-13, but not as originally framed.** Read Hermes v1's real message
> struct (`capsules/hermes/init.4th`, blocks 4100/4105/4143, item 4.2): `MSG-CELLS` is 9
> cells — `TYPE, FROM, TO, PADDR, PLEN, STADIUM-CELL, SEQ, CH, ORIG-TYPE` — at 8 bytes/cell
> (`cell_t` is `int64_t`/`long`, `include/vm.h:71-75`), i.e. **72 bytes**, already over
> §23.3's whole proposed 64-byte cell before any payload. And the payload itself is
> **not inline at all**: `MSG-SEND` (`:208-213`) takes a caller-supplied `paddr plen` —
> wherever the caller already put the bytes (a string literal via `S"`, a block buffer) —
> and stores only the pointer and length in the struct. There is no fixed-size inline
> payload field to check a message against. So §23.4 #2's literal question ("does a
> typical message fit in the 32-byte inline payload") is **moot, not answered**: the
> shipped design didn't adopt §23.3's speculative 64-byte-cell/32-byte-inline-payload
> scheme for messages at all, it used a larger fixed control block plus out-of-line
> pointer/length indirection instead. Closing as settled-by-divergence — the real
> implementation went a different direction than the design question assumed, which is
> itself the answer; §23.3's cell-size numbers were never made load-bearing for Hermes
> messages and nothing here depends on reconciling them.
---
## E. Documentation debt