57aff40228
docs/ was ten files where a plan, a description, a guide and a bug report all
sat next to each other. It is now architecture/ (what SchOS is), plan/ (what it
will be), guides/ (how to work on it) and history/ (why it is like this), with
an index that states the one rule holding it together: when something is
finished it moves from plan/ to architecture/ and is rewritten as a description
of the thing rather than a record of building it.
A ticked checkbox says the work happened. It does not say what the work
*produced*, and six months later the checkbox is all that is left. The network
stack proved the point: finished, verified end to end, and for a month the only
description of it anywhere was a checkbox four levels of indentation deep.
So roadmap.md went from 534 lines to 181 -- nothing deleted, the done work
graduated. Seven subsystems that were finished and undescribed now have
descriptions: boot, kernel, syscalls, filesystem, networking, graphics, usb,
init. Every one ends with "What it does not do", which is the section that pays;
a document listing only strengths is marketing, and the reader who needs it most
is the one about to trip over a limitation nobody wrote down.
schfs.md still opened with "phases 1 through 3 1/2 are done, phase 4 is next"
long after all five had landed. It is a description now, with the phase record
and the hard-won bugs moved to history/.
Three corrections found on the way, all load-bearing:
* projects/schcom/README.md claimed SCM_RIGHTS was done. There is no
sendmsg/recvmsg in the kernel at all, and an entire GUI plan rested on it.
* The root README said "No TCP/IP" months after the stack landed.
* history/kernel.md sec.7 was marked "in progress" on a problem that process
groups solved.
Also adds plan/1.0.md, which draws a finish line so the open list stops being
infinite, and marks schwm/ and schde/ superseded: in Wayland the compositor is
the window manager, so that split dissolves rather than being abandoned.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
6.1 KiB
| name | description | metadata | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| schunix-roadmap-and-projects | The agreed roadmap through USB, GPU, fonts, network and the GUI; Schcom/SchWM/SchDE and the installer live in projects/, outside the OS tree |
|
Set out 2026-08-04. Recorded in docs/plan/roadmap.md; the naming and the
split are Nexoniarz's.
Order asked for: USB → GPU → OTF/TTF → network + sockets → GUI → installer. Kept, with one dependency fix: shared driver infrastructure came first (schunix-driver-infrastructure), because it was the first step of USB rather than a detour from it.
The GUI stack, all three named by Nexoniarz and all in projects/:
- Schcom — Schunix Compositor. Owns the display and input; composites client buffers. Policy is not its job.
- SchWM — window manager, a privileged Schcom client.
- SchDE — desktop environment: panel, launcher, settings.
- schinst — installer, installation environment, and
.siptooling.
projects/ is at the repo root and is not part of the kernel build —
things that run on Schunix, not things that are Schunix. They link against
the sysroot libc and never against kernel headers. The reason is that each is
larger than the kernel will be for a long time, and grown in-tree the
boundary would blur until "does Schunix boot" stopped having a clear answer.
The two hard blockers before Schcom can start, both kernel work:
- Unix domain sockets.
socket()is still aNO_LINUXstub. Needed for the client protocol and forSCM_RIGHTS— a pipe cannot carry a buffer handle. Build these before TCP/IP; they are simpler and they are what the socket layer's shape should be designed around. - Raw input events — an evdev-style
/dev/input. Input only arrives cooked through the tty line discipline, line-buffered to one foreground process, which is not usable by a compositor.
shm and framebuffer mmap are already done (schunix-shm-and-mmap).
.sip = Schunix Installation Package, modelled on WIM: file-based rather
than block-based, so one file holds a whole tree, applies to any partition
size, and dedups across images. Most of it exists — tools/mkschfs.c and
tools/mkfs.c already do content dedup with an (st_dev, st_ino) fast path.
mksip should share that code.
Order changed 2026-08-09: Schcom and SchAPI come before the installer
Nexoniarz: the GUI stack is what is actually needed, the installer can wait.
Schcom v0 is done — see schcom-v0. SchAPI/libschunix is still not
started, and is the other half of what was asked for.
projects/ has build glue now: make projects builds against the sysroot libc
and stages into sysroot/bin. It is not a dependency of the OS build and
make never descends there.
The installer, scoped 2026-08-09 (deferred, not cancelled)
A live CD is off the list. The ISO boots a complete system from the ramdisk, so it already is the live environment; an installer makes a mountable disc redundant. That drops the ATAPI driver and ISO 9660 filesystem entirely — see schunix-iso-boot.
Nexoniarz chose the ambitious shape on both open questions:
- Both firmwares from the start: GPT with a FAT ESP and a SchFS partition, bootable on BIOS and UEFI. Needs a FAT writer and GPT code inside the OS before anything can be installed at all.
.sipfirst, rather than copying the running root. The installer applies a package;mksipcomes before anything installs.
Dependency chain, each stage separately verifiable:
- Raw block device — done, commit
66152ad./dev/hda,/dev/hdb, major 8, minor = IDE device number. Verified against the host as an independent oracle in both directions. Limit:devswpasses the offset as a 32-bituint, so a raw disk stops at 4 GB — widen before installing to real hardware. .sipformat +mksip, sharing the dedup path inmkschfs.c. Test it the way the SchFS round-trip is tested: build, apply,diff -ragainst the source tree (schfs-phase2-mount).- In-OS tooling: GPT writer, FAT ESP writer, native SchFS formatter.
- Bootable target: bootblock + stage2 for BIOS, ESP + BOOTX64.EFI + kernel for UEFI.
schinstinprojects/, driving all of it.
Confirmed order (2026-08-05): finish USB, then sockets + raw input, then virtio-gpu.
Doom moved (2026-08-05). It was "explicitly last"; it is now the
acceptance test — "an OS that doesn't run Doom is not a real OS".
fbDOOM at that. It is a real load test: framebuffer mmap, raw termios,
file I/O, allocator and timing, all at once. Everything on that list already
exists except possibly gettimeofday/nanosleep resolution, so it could
be attempted today — it needs no sockets, USB, virtio-gpu or fonts.
It is a test, not a component — clarified by Nexoniarz: built and run to
prove things work, never shipped in the system. That disposes of licensing
entirely, since nothing is redistributed. Belongs with the test tooling (a
make doomtest, same shape as make crashshot), not in cmd/ or the
sysroot. If it were ever shipped the licensing returns: engine is GPL-2.0
(fine in ports/, never cmd/), and the WAD would have to be Freedoom
(BSD-3-clause) because doom1.wad is not redistributable.
Sized honestly and not to be underestimated: OTF/TTF is a rasteriser plus a variable-width glyph cache, and the console assumes a fixed 8x16 cell grid throughout — proportional text is a new rendering layer, not a font swap.
Fonts must be public domain or very permissive — "PD0", clarified 2026-08-05 (the earlier note read it as "CY-NO", which was never a real thing). CC0 is ideal; MIT/BSD/Apache fine. SIL OFL is usable but carries a rename-if-modified obligation, so read it first. A font ships inside every image, so its licence attaches to the image — see schunix-licensing.
First GPU driver should be virtio-gpu, not Intel/AMD: public spec, QEMU implements it, and it teaches the resource/flush model that a raw framebuffer never will. Doom stays last. See nexoniarz-sharing-preference.