| Filename | Latest commit message | Latest commit date |
|---|---|---|
c0ed23cc56
The failure this is against is not scope creep. It is abandonment by promotion:
a thing gets built to the point where it works, the next thing becomes more
interesting, and the first is left in a corner -- in the tree, not finished, not
deleted, and not in any list. Enough of those and the tree stops matching its
own documentation.
docs/plan/1.0.md now holds the register, and it is the only place anything
half-built is listed. Four sections, because the kinds are genuinely different:
built and connected to nothing (the text layer, a font from disk, socket
activation, wait_vblank); started and stopped part-way (foundations 2-5, hybrid
H2, Schcom v0, a released PCI device that nothing brings back); named in a "what
it does not do" and still true; and frozen -- scoped, unstarted, not to be
started. The rule is that nothing enters except by being finished or deleted,
and that adding a row requires closing one.
1.0.md already said "two things in flight, never three". It was right and it was
not being followed.
Then the corners themselves, because a register written over a tree full of them
is just a longer list:
- cmd/init is deleted. Nothing had execed /bin/init since initcode.S changed
to /bin/schinit; it was built and installed on every image as an unreachable
fallback, and an unreachable fallback rots rather than saves.
- projects/schwm/ and projects/schde/ are deleted. Both said "to be deleted"
in their own first paragraph, which proves only that a directory marked for
deletion is not deleted by being marked. README-only, no code lost, and the
arguments each made are moved into wayland.md where they are still true.
- projects/schcom/schcom and schcom-demo were tracked binaries. Untracked, and
.gitignore'd.
Three code comments and one document described a boot that has not happened
since
|
||
| .. | ||
| schcom | ||
| schfs-linux | ||
| schinst | ||
| README.md | ||
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.