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
57 lines
2.9 KiB
Markdown
57 lines
2.9 KiB
Markdown
# 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. |
|
|
| `schwm/` | SchOS Window Manager. Window placement, decoration, focus, on top of Schcom. |
|
|
| `schde/` | SchOS Desktop Environment. Panel, launcher, settings, file manager. |
|
|
| `schinst/` | The installer, the installation environment, and `.sip` tooling. |
|
|
| `schfs-linux/` | SchFS as a filesystem for Linux. FUSE first, a kernel module later. |
|
|
|
|
**`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.
|
|
|
|
They stack: SchDE needs SchWM needs Schcom needs the kernel. Nothing points
|
|
the other way, and nothing here is a dependency of the kernel build.
|
|
|
|
## Status
|
|
|
|
All four are scoped and none is started. What each is waiting on is written
|
|
in its own README, and the ordering is in `docs/plan/roadmap.md`.
|
|
|
|
The short version: Schcom cannot start until the kernel has **unix domain
|
|
sockets** (for the client protocol and for passing buffer handles) and **raw
|
|
input events** (a `/dev/input` that bypasses the tty line discipline).
|
|
Shared memory and framebuffer mmap are already done.
|