SchOS/docs/architecture
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Nexoniarz 7c8cf51941 schfs: records at arbitrary offsets are packed, and the compiler is told
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
2026-09-12 17:56:36 +02:00
..
boot.md docs: four directories, and a rule for when a thing leaves the roadmap 2026-09-12 17:13:35 +02:00
devices.md docs: four directories, and a rule for when a thing leaves the roadmap 2026-09-12 17:13:35 +02:00
filesystem.md docs: four directories, and a rule for when a thing leaves the roadmap 2026-09-12 17:13:35 +02:00
graphics.md docs: four directories, and a rule for when a thing leaves the roadmap 2026-09-12 17:13:35 +02:00
init.md docs: four directories, and a rule for when a thing leaves the roadmap 2026-09-12 17:13:35 +02:00
kernel.md docs: four directories, and a rule for when a thing leaves the roadmap 2026-09-12 17:13:35 +02:00
networking.md net: a frame wakes the stack, instead of waiting for the clock 2026-09-12 17:23:46 +02:00
README.md docs: four directories, and a rule for when a thing leaves the roadmap 2026-09-12 17:13:35 +02:00
schfs.md schfs: records at arbitrary offsets are packed, and the compiler is told 2026-09-12 17:56:36 +02:00
syscalls.md docs: four directories, and a rule for when a thing leaves the roadmap 2026-09-12 17:13:35 +02:00
usb.md docs: four directories, and a rule for when a thing leaves the roadmap 2026-09-12 17:13:35 +02:00

The system, layer by layer

What SchOS is today. Everything in this directory is built and running; what is merely intended lives in ../plan/.


The names, and what each one covers

uname -s reports SchIFT, the way every Unix reports its kernel rather than its distribution.

Layer Name What it is
System SchOS The distribution — kernel, userland, tooling
Kernel SchIFT Multi-core x86-64 kernel with a modular VFS
Filesystem SchFS Transactional, copy-on-write, the root filesystem
API SchAPI The native programming interface — designed, not built
Compositor Schcom Owns the display; v0 runs

The stack, bottom to top

      ┌─────────────────────────────────────────────────┐
      │  toybox   mksh   musl        first-party cmd/   │   userland
      ├─────────────────────────────────────────────────┤
      │  schinit — PID 1, job manifests, supervision    │
      ├─────────────────────────────────────────────────┤
      │  syscall table — Linux numbering, one .inc file │   ← the ABI seam
      ╞═════════════════════════════════════════════════╡
      │  VFS │ sockets │ signals │ mmap │ poll │ procfs │
      ├──────┴─────────┴─────────┴──────┴──────┴────────┤
      │  SchFS  │  lwIP  │  text/gfx  │  buffer cache   │
      ├─────────┴────────┴────────────┴─────────────────┤
      │  device model — class vtables, bus binding      │
      ├─────────────────────────────────────────────────┤
      │  drivers: xHCI  e1000  virtio-gpu  VBE  IDE  PS/2│
      ├─────────────────────────────────────────────────┤
      │  scheduler │ paging │ traps │ IRQ │ SMP │ DMA   │   SchIFT core
      └─────────────────────────────────────────────────┘
                            ▲
                   UEFI loader (boot/uefi)

The two seams that matter are the syscall table and the device model. Above the first, software is ordinary and portable — musl and toybox are unmodified. Below the second, a driver never names its consumer and a consumer never names a driver.


Where it came from

SchOS began as xv6 and is now mostly something else. What survives from xv6 is the shape of the process table, the sleep/wakeup discipline, and the buffer cache. What has been replaced: the scheduler and trap path (rewritten for x86-64 and for more than one processor), the memory manager, the entire filesystem, the syscall layer, and every driver.

That inheritance is worth knowing when reading the code, because the parts that still look like xv6 follow xv6's conventions and the parts that do not, do not.


The documents

Read in this order if you are new:

boot.md Firmware to the first userspace process. The shortest path through the whole system.
kernel.md Memory, processes, scheduling, traps, signals, SMP.
syscalls.md The one table everything is generated from, and how a musl binary runs unmodified.
filesystem.md The VFS, the buffer cache, mounts, procfs.
schfs.md The copy-on-write root filesystem.
devices.md Buses, classes, binding, and the vtables consumers talk to.
usb.md xHCI, the USB core, and the three class drivers.
graphics.md Framebuffer, text rendering, the console, and PSOGM.
networking.md NIC drivers, lwIP, and both socket families.
init.md schinit and the job manifests.

Three rules that hold across all of it

The kernel and the host tools compile the same SchFS source. mkschfs cannot disagree with the kernel about the on-disk format, because there is only one implementation. Format bugs are found on the host, where a test takes a second instead of a boot.

Syscalls are declared in exactly one place. kernel/sys/table.inc. The constants, the dispatch table and the Linux translation map are all generated from it, so a syscall cannot be half-registered.

A list you can read beats a list assembled by side effects. Drivers are written out by hand in kernel/drivers/registry.c rather than collected by a linker section, and platform devices are registered in one function rather than inside each driver's init. The tradeoff is deliberate: self-registration is nicer to write, and it means the list of what is in your kernel is not written down anywhere you can read.