FABRIC-3.md §X.4: correct a false claim about kmalloc.c lacking block splitting
Build / build-aarch64-iso (push) Waiting to run
Build / build-amd64-iso (push) Waiting to run
Build / build-riscv64-img (push) Waiting to run

The claim ("coalesces but doesn't split") was never actually checked
against kmalloc.c -- it was carried over from alloc_kernel.c's own doc
comment about itself and mis-applied to a different file. Asked to fix
it, re-reading kmalloc.c showed allocate_from_block() already has a
complete, unconditional splitting implementation. Nothing was broken;
correcting the record instead of "fixing" working code.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78
This commit is contained in:
Robert Allan James
2026-09-07 14:34:03 -04:00
co-authored by Claude Sonnet 5
parent b106a4b0b5
commit 8471d529bc
+15 -7
View File
@@ -1656,13 +1656,21 @@ amd64/aarch64/riscv64 (one aarch64 attempt hit an unrelated, already-documented
hiccup — empty log, boot never left firmware — and passed cleanly on immediate retry with no
rebuild).
**Not addressed by this fix, still open:** the free list `kmalloc.c` provides is coalescing but
still first-fit without block *splitting* — a different, smaller-grained fragmentation lever
than the one that was actually hit here. Per-VM dictionary sizing (shrinking what each
`WIREBIND` user VM's word set actually needs — it currently carries the full set, including
things like `TTF-TEXT`/`SCROLL-BACK`/`KBD-SCAN` a non-console user session may not need) remains
a separate, unexplored lever, not required by this fix but still worth revisiting if identity
count grows large enough for it to matter again.
**Correction, 2026-09-07 (same day):** an earlier draft of this section claimed `kmalloc.c`'s
free list "coalesces but doesn't split." That was wrong — never actually verified before being
written, just carried over from `alloc_kernel.c`'s own doc comment about *itself* lacking
splitting, mis-applied to `kmalloc.c` too. Re-read on request: `allocate_from_block()` already
implements real, unconditional block splitting (`can_split()`/`min_splittable_payload()`) — a
free block larger than a request needs, with enough leftover to be worth it, gets its remainder
carved off and threaded back onto the free list as its own block. Combined with
`coalesce_neighbors()` on every `kfree()`, this allocator already has both halves of real
fragmentation resistance. Nothing to fix here.
**Not addressed, still open:** per-VM dictionary sizing (shrinking what each `WIREBIND` user
VM's word set actually needs — it currently carries the full set, including things like
`TTF-TEXT`/`SCROLL-BACK`/`KBD-SCAN` a non-console user session may not need) remains a separate,
unexplored lever, not required by anything above but still worth revisiting if identity count
grows large enough for it to matter again.
**Also flagged, not touched (not asked):** `Makefile.starkernel`'s
`printf '$(KERNEL_ARGS)\n' > starforth.cfg` breaks when `KERNEL_ARGS` starts with `--` (dash's