From 4891fd0067f89f7f7e0fb4ce01fe6dc00cfcc59b Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Tue, 25 Aug 2026 15:00:49 -0400 Subject: [PATCH] FABRIC-2.md: drop GPT partitioning for home-blocks USB drive, whole-device layout instead Checked the math with Captain Bob: a PBAM for ~15GB of user blocks needs only ~1.92MB (15M blocks / 32768 per 4KB page), fitting easily alongside identity/credential/PKI material in a 1GB reserved region. No partition table needed -- same whole-device pattern artemis.img already uses today, just with a generously fixed ~1GB reserved region instead of tight bam_start+bam_devblocks packing. Eliminates the GPT-parser work item entirely (no GPT code exists in src/starkernel/ today). Confirmed no conflict with Milestone 8's USB boot drive, which is a separate physical drive (flashed starkernel.iso) with its own independent GPT/ESP need. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01CXjAPTEKrgY2Mrk25KoLDn --- FABRIC-2.md | 47 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 32 insertions(+), 15 deletions(-) diff --git a/FABRIC-2.md b/FABRIC-2.md index 02fd2be..13f4ccc 100644 --- a/FABRIC-2.md +++ b/FABRIC-2.md @@ -3980,23 +3980,40 @@ Depends on Milestone 2 existing (needs a real device to test against, though the identity→range derivation logic itself could be unit-tested against the existing RAM/ RAMDRIVE/DISK devices first without waiting for USB). -**Decided with Captain Bob, 2026-08-22 — USB thumb drives get GPT-partitioned, unlike +**Superseded 2026-08-25 — GPT partitioning dropped, whole-device layout instead (same +pattern `artemis.img` already uses).** The 2026-08-22 decision below (kept struck-through for +history) called for a GPT-partitioned drive; revisited when the math was actually checked. +Reference/target physical drive size: **16GB**. A straight bitmap PBAM (`blk_volume_meta_t`'s +existing format, 32768 blocks tracked per 4KB page) for ~15GB of user blocks needs only +~1.92MB (15M blocks ÷ 32768 × 4KB) — comfortably inside a 1GB reserved region alongside +whatever the identity/credential/PKI material (Section U/V's PKI work, not yet designed in +detail) turns out to need, with ~998MB headroom to spare. So: **no partition table at all** — +the whole drive is one `blk_dev_slot_t`-style device, header at devblock 0, exactly like +`artemis.img` today, just with the reserved region sized to a generous fixed ~1GB (header + +PBAM + identity material) instead of the tight `bam_start + bam_devblocks` packing the current +format computes on the fly. Everything after that reserved region is the user-visible +block-storage LBN range, attached via `blk_subsys_attach_device()` the normal way (matching +Artemis's own precedent exactly, not a new mechanism). **This eliminates the GPT-parser work +item below entirely** — no GPT read/write code needs to exist in `src/starkernel/` at all for +this drive. Checked for conflicts: Milestone 8's USB drive (bare-metal boot demo) is a +*different* physical drive — a flashed `starkernel.iso` boot stick — not the home-blocks +identity drive, so dropping GPT here doesn't touch that milestone's own (separate, UEFI-driven) +GPT/ESP requirement. `disk/usb-thumbdrive-test.img` stays a small 64MB test fixture regardless +— a 16GB file isn't practical to commit to this repo; 16GB is the real-world design target the +*layout math* is sized around, not the size of every test image. + +~~Decided with Captain Bob, 2026-08-22 — USB thumb drives get GPT-partitioned, unlike `artemis.img`'s current whole-device STFR/v2 header (`blk_compute_fresh_geometry()`, `src/block_subsystem.c:405-429` — that layout writes the header directly at devblock 0 of the -whole device, no partition table).** Reference/target physical drive size: **16GB**. Layout: -one GPT partition ≈1GB for LithosAnanke metadata (identity/credential/ACL material — Section -U/V's PKI work, not yet designed in detail), remainder (≈15GB) as a second partition holding -the block-storage region that gets attached into the LBN chain via `blk_subsys_attach_device()` -(pointed at that partition's start LBA, not devblock 0 of the raw device). Sizing explicitly -tentative — "we'll figure it out" if 1GB proves too small once the metadata format is designed. -**Not yet a punch-list item, and not yet built: this repo has no GPT parser anywhere in kernel -code today** (the riscv64 boot disk's GPT layout, `Makefile.starkernel`'s `sgdisk` call, is -host-side build tooling for the UEFI ESP, not kernel-read code) — reading/writing a real GPT -partition table from `src/starkernel/` is new, unstarted work this decision now requires, -before `blkio_usb.c` can hand `blk_subsys_attach_device()` a correctly-offset device view. -`disk/usb-thumbdrive-test.img` stays a small 64MB test fixture regardless — a 16GB file isn't -practical to commit to this repo; 16GB is the real-world design target the *layout math* is -sized around, not the size of every test image. +whole device, no partition table). Layout: one GPT partition ≈1GB for LithosAnanke metadata, +remainder (≈15GB) as a second partition holding the block-storage region that gets attached +into the LBN chain via `blk_subsys_attach_device()` (pointed at that partition's start LBA, not +devblock 0 of the raw device). Not yet a punch-list item, and not yet built: this repo has no +GPT parser anywhere in kernel code today (the riscv64 boot disk's GPT layout, +`Makefile.starkernel`'s `sgdisk` call, is host-side build tooling for the UEFI ESP, not +kernel-read code) — reading/writing a real GPT partition table from `src/starkernel/` was new, +unstarted work this decision required, before `blkio_usb.c` could hand +`blk_subsys_attach_device()` a correctly-offset device view.~~ - [ ] Design the identity→block-range derivation function's exact input/output (Section V area A open point: currently zero decisions made, not even a function signature)