From c47215821c0b3381d1a8aa9e1c73dea68d52c537 Mon Sep 17 00:00:00 2001 From: Daniel Samson <12231216+daniel-samson@users.noreply.github.com> Date: Mon, 10 Aug 2026 04:15:03 +0100 Subject: [PATCH] =?UTF-8?q?docs:=20the=20second=20engine=20is=20built=20?= =?UTF-8?q?=E2=80=94=20exFAT=20+=20proven=20harness=20reuse=20(S4)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Flip the storage docs to record exFAT as a built second engine reusing the shared filesystem harness wholesale (the reuse the architecture promised): full read + write, directories, rename, on-disk up-case folding, routed by VBR to fat or exfat at an exfat- id-path. Note the two surface limits shared by BOTH engines as vfs-layer concerns, not exFAT shortcuts: u32 file offsets (a 4 GiB cap) and ASCII-only names. --- .../storage-architecture.md | 9 +++++++-- .../storage-design-rationale.md | 19 +++++++++++++------ 2 files changed, 20 insertions(+), 8 deletions(-) diff --git a/docs/file-system-development/storage-architecture.md b/docs/file-system-development/storage-architecture.md index c2e4d8b..028d747 100644 --- a/docs/file-system-development/storage-architecture.md +++ b/docs/file-system-development/storage-architecture.md @@ -18,8 +18,13 @@ > its own `/volumes/` path with its own supervision. The boot volume is > identified by **content** (a volume backs `/system/configuration` + `/system/logs` > only when it resolves `/system/configuration` on its own media), so it works as -> any partition of any device. **Still pending**: the `filesystem UUID` rung and -> a second engine (exFAT, S4); the volume manager *consuming* `medium_changed` +> any partition of any device. exFAT is **built** as a second engine +> (`system/services/exfat`): full read + write, directories, rename, and on-disk +> up-case folding, reusing `library/kernel/file-system-harness` wholesale — the +> reuse claim, proven — and a volume routes to fat or exfat by its VBR, at an +> `exfat-` id-path. **Still pending**: the `filesystem UUID` rung (ext- +> family superblocks, which need such an engine); the volume manager *consuming* +> `medium_changed` > (removal is detected by device-presence polling; the event is published but only > a card-reader medium change needs the subscription); the remount-on-replug > end-to-end (the logic is in place; QEMU can't re-present the boot-controller diff --git a/docs/file-system-development/storage-design-rationale.md b/docs/file-system-development/storage-design-rationale.md index dd51561..9159f43 100644 --- a/docs/file-system-development/storage-design-rationale.md +++ b/docs/file-system-development/storage-design-rationale.md @@ -104,12 +104,19 @@ and /system/logs), closing the two-sticks question honestly. **Filesystems (per volume, one process).** The proven unit everywhere from Plan 9's `dossrv` to Minix to Fuchsia: block-client + engine + file-protocol provider in one binary, one process per volume (9front practice; per-volume -fault isolation is what our supervision makes cheap). fat's shell becomes a -shared *filesystem harness* library before a second engine is written; a -partition walk is added in the volume manager (`partition.zig`) — the engine's -own MBR walk currently remains alongside it; write caching stays -inside the process (the anti-fsyncgate rule). Each mounts its prefixes into the -kernel mount table itself, exactly as today. +fault isolation is what our supervision makes cheap). fat's shell became a +shared *filesystem harness* library (`library/kernel/file-system-harness`), and +the second engine — **exFAT**, `system/services/exfat` — now reuses it wholesale: +the reuse this design promised, proven. exfat is nothing but the exFAT engine + +a near-clone of fat's thin service, full read + write + directories + rename + +on-disk up-case folding, differing only in the format it wraps. A partition walk +lives in the volume manager (`partition.zig`), which recognizes fat vs exFAT by +VBR and routes each to its engine; write caching stays inside the process (the +anti-fsyncgate rule). Each mounts its prefixes into the kernel mount table +itself. Two surface limits are shared across both engines and are the vfs +layer's, not an exFAT shortcut: file offsets are u32 (a 4 GiB addressable cap), +and file names are ASCII bytes (a non-ASCII unit becomes `?`) — teaching the vfs +name layer UTF-8 is a separate cross-cutting change. **Kernel: two small changes only.** `fs_unmount` gains ownership (only the mounting endpoint's holder may unmount — possession-is-capability, consistent