| Filename | Latest commit message | Latest commit date |
|---|---|---|
A leaf's value area holds variable-length records end to end, so a record begins wherever the one before it finished -- a multiple of 8 only by luck. The code reads them by casting a pointer into the block, which tells the compiler they are aligned when they are not. That works on x86, which is why it has never shown as a bug, and it is undefined in C. A compiler entitled to assume 8-byte alignment may emit an instruction that requires it, and the failure would arrive at a different optimisation level or on a different architecture looking like filesystem corruption rather than like codegen. UndefinedBehaviorSanitizer reported 31 of them across obj.c, objw.c, attr.c and space.c. Seven types now carry SCHFS_PACKED: dirent_rec, extent, extref, index_rec, attr_rec, snap and inode. Two of those -- attr_rec and inode -- were never reported, because schfs_objtest does not reach an unaligned instance of either. They were latent rather than absent, and casting into a leaf is the same lie whether or not a test has caught it yet. NO ON-DISK LAYOUT CHANGED, and that was measured before the annotation was applied rather than assumed: every one of these already carries explicit `pad` fields and therefore has no implicit padding, so sizes and member offsets are identical with and without it. Seven _Static_asserts now pin the sizes, because a record that silently grows misreads every existing volume from that point on and looks like corruption rather than like a struct that changed. schfs_node_hdr, schfs_item, schfs_kptr and schfs_uberblock are deliberately left alone. The node header is exactly 32 bytes, so the items and key pointers after it are already 8-aligned, and annotating them would cost byte-wise access on the tree's hottest paths to fix a problem they do not have. Verified by reading an image written before the change: schfs_fsck --check passes on structure, checksums, key ordering, data blocks and derived free space, and the kernel mounts its own root unchanged. Also here: mkschfs passed a null pointer to qsort for an empty directory. Every implementation ignores it when the count is zero; the standard does not say they have to. make schfs-check now runs with no sanitizer output at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2 |
||
| .. | ||
| 1.0.md | ||
| foundations.md | ||
| hybrid.md | ||
| init.md | ||
| README.md | ||
| roadmap.md | ||
| schapi.md | ||
| wayland.md | ||
What happens next
Everything in this directory is unbuilt. When a piece of it is finished it leaves — deleted from here, rewritten as a description in ../architecture/. See the rule.
Read 1.0.md first.
It draws a finish line and puts most of the work below on the far side of it. Anything not named there is not being worked on, and the documents in this directory describe more than 1.0 contains.
The three current decisions
Taken together, because they turn out to need the same foundation.
| wayland.md | The GUI stack becomes Wayland. SchWM and SchDE are deleted; Schcom survives and changes its wire format. |
| hybrid.md | The kernel becomes hybrid — drivers move out into userspace processes, starting with the GPU. |
| init.md | PID 1 stops being a process and becomes a role the kernel guarantees is filled. |
And the one they all wait on:
| foundations.md | Descriptor passing, shared memory, sockets in the filesystem. The critical path. |
And the one that says which parts of the above are actually being worked on:
| 1.0.md | The finish line. Four gates, and everything else explicitly deferred. |
Two longer-horizon documents sit behind these: schapi.md, the API layering and the compatibility promise, and roadmap.md, which holds everything still open that is not one of the three above.
The order
Set by 1.0.md, which is the authority. In short:
0. Fix what is already wrong — first
Not a document of its own; it is Gate 0 of 1.0.md, assembled from the What it does not do sections in ../architecture/.
Before any new capability, and the reason is the one that put
netdev_selftest() before the TCP/IP stack: a compositor built on a kernel with
an unexplained hang and a socket layer that reports success for things it did not
do will fail in ways indistinguishable from its own bugs.
1. foundations.md — the critical path
Both the Wayland work and the hybrid work stop here. Descriptor passing and shared memory are the substrate for handing a buffer to a compositor and for handing a device to a driver process. Doing it once for both is the entire reason these are one plan rather than three.
2. init.md — before the desktop, not after
A compositor being brought up for the first time crashes constantly, and something that restarts it and says why is worth far more during that work than at the end of it.
3. wayland.md — with the GPU driver still in the kernel
W1–W3 and a terminal. W4 and W5 are post-1.0.
4. hybrid.md — after 1.0
Deliberately last: designing a userspace driver interface with no driver consuming it produces an interface that is wrong in ways nobody can see. The compositor is the demanding consumer that makes the interface judgeable, so it has to exist first.
In one sentence
Fix what is broken, build the descriptor-passing and shared-memory substrate, make init survivable, put a terminal on the screen — and only then use the compositor as the pressure that shapes the userspace driver interface.
What this plan does not address
Stated here so it is not mistaken for covered:
- No IOMMU, so the hybrid work isolates against bugs and not against a hostile driver.
- No page cache, so
foundations.mddelivers amemfdand not a general answer to shared file mappings. The general answer is still owed. - No dynamic linking, so no Mesa, no accelerated clients, and no third party
shipping a
.sofor anything. - A new compatibility surface between PID 1 and PID 2, created by a plan whose own schapi.md §3 spends a section warning about those.
- The three open networking items —
getsockname, routing, and interrupt-driven receive — are untouched by any of this and still open. They are in roadmap.md.