SchOS/projects

projects/

Things that run on SchOS rather than things that are SchOS.

Everything above this directory — kernel/, boot/, lib/, cmd/, include/ — is the operating system: it boots, it owns the hardware, and it is one program that either works or does not. Everything in here is an ordinary program that talks to it through syscalls, exactly as toybox does.

The split exists because the alternative gets bad quickly. A compositor, a window manager and a desktop are each larger than the kernel will be for a long time. Grown inside the OS tree they would blur into it: a compositor would start reaching into kernel headers because they are right there, the build would grow a dependency from the kernel to a GUI, and "does SchOS boot" would stop having a clear answer. Keeping them separate forces the boundary to be a real interface — syscalls and protocols — rather than a shared header nobody meant to share.

Concretely, code in here:

• links against the sysroot's libc, never against kernel headers
• talks to the kernel only through syscalls and /dev
• can be built, run and debugged without rebuilding the kernel
• may be split into its own repository later without untangling anything

What lives here

Directory	What it is
schcom/	SchOS Compositor. Owns the display, composites clients, routes input.
schinst/	The installer, the installation environment, and .sip tooling.
schfs-linux/	SchFS as a filesystem for Linux. FUSE first, a kernel module later.

schwm/ and schde/ used to be here and have been deleted. In Wayland the compositor is the window manager — there is no protocol by which a second process places another's windows — and a panel or a launcher is an ordinary client that needs no home of its own until one is written. Both directories held a README and no code, and both had said "to be deleted" for long enough to prove that a directory marked for deletion is not deleted by being marked. What they argued for survives as a module boundary inside Schcom; see docs/plan/wayland.md.

schfs-linux/ is written to stand on its own. It does not mention SchOS anywhere, and that is deliberate rather than an oversight: it is intended to be the first piece released, and it has to make sense to somebody who has never heard of the OS it came from — a filesystem is judged as a filesystem. The connection can be made later, once there is a finished system to connect it to.

Practically, that means anything added there needs its own licence header, its own README framing, and no cross-references into this tree. It shares the format with kernel/fs/schfs/, not the prose.

Nothing here is a dependency of the kernel build, and nothing here is pointed at by anything above it.

Status

schcom/ has a v0: 715 lines that run, over a wire format of its own. That wire format is superseded — the compositor moves onto Wayland, keeping the architecture and replacing the protocol. See docs/plan/wayland.md.

Everything Schcom was blocked on in the kernel now exists: unix domain sockets, raw input events, shared memory, framebuffer mmap, and — as of the descriptor passing work — SCM_RIGHTS, which is the one thing a Wayland client cannot be written without. What is still missing is a shareable memory object, item 2 of docs/plan/foundations.md: a Wayland buffer is a file descriptor for memory, and a System V segment id is not one.

schinst/ and schfs-linux/ are scoped and unstarted, and are frozen — see docs/plan/1.0.md.