ed81f9a07a
SchOS will not write its own compositor. projects/schcom, its test and its make targets are deleted. roadmap.md section 5 is now the road to Wayland (udev/eudev, a /sys/devices tree and uevent netlink, libinput and libseat, a DRM device via the GPU plan) and 5b is the boot manager rework (Niveus/skeuomorphic UEFI GUI). XLibre, Xorg or a Wayland compositor from Alpine, whichever suits; Xorg for now. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EVRhxi9zpdW2uDUN4FVcao
52 lines
2.7 KiB
Markdown
52 lines
2.7 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 desktop environment is 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 |
|
|
|------------|-----------------------------------------------------------------|
|
|
| `schinst/` | The installer, the installation environment, and `.sip` tooling. |
|
|
| `schfs-linux/` | SchFS as a filesystem for Linux. FUSE first, a kernel module later. |
|
|
|
|
`schcom/`, `schwm/` and `schde/` used to be here and were **deleted**: SchOS does not write its own compositor, window
|
|
manager or desktop. The desktop is Xorg with Window Maker ([`docs/architecture/desktop.md`](../docs/architecture/desktop.md)),
|
|
and the road to Wayland is Alpine's compositors on top of udev and a DRM device ([`docs/plan/roadmap.md`](../docs/plan/roadmap.md) §5).
|
|
|
|
**`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
|
|
|
|
`schinst/` and `schfs-linux/` are scoped and unstarted, and are **frozen** -- see
|
|
[`docs/plan/1.0.md`](../docs/plan/1.0.md).
|