59aff881ac
1.0: the acceptance test drops its reboot clause (a live system is the finish line) and passes. Schcom is kept with a job: the installer's GUI first, SchDE on top later (roadmap section 5). The old 'LDLS ships no Linux code' policy is gone from ldls/devices/licensing/Makefile/.gitignore/ldlsd; NOTICE records the r8169 modules (GPL-2.0-only) and the Realtek firmware. The download button points at the v0.1.0 release asset; the stale 64 MB ISO under docs/Website is removed. mkaroot.sh's -dumbSched comment no longer claims SchOS has no threads. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EVRhxi9zpdW2uDUN4FVcao
61 lines
3.4 KiB
Markdown
61 lines
3.4 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. v0 runs; the plan is for it to draw the installer, and later a desktop (SchDE) on top. |
|
|
| `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 were **deleted**: both held a README and no code. The window manager
|
|
is Schcom's own business now (a compositor is its window manager), and **SchDE**, a panel, launcher and the rest,
|
|
comes back as ordinary clients of Schcom once there is something for them to run on. Until then the desktop is
|
|
Xorg with Window Maker ([`docs/architecture/desktop.md`](../docs/architecture/desktop.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/` is a compositor v0, 715 lines that run, over a wire format of its own. It is **kept, with a job**: the
|
|
installer's GUI ([`docs/plan/roadmap.md`](../docs/plan/roadmap.md) §5) is its first real client, and if it grows
|
|
into something actually useful it becomes SchOS's own desktop, SchDE on top. Everything it was blocked on in the kernel
|
|
exists (Unix sockets, descriptor passing, `memfd`, evdev, framebuffer `mmap`); what it lacks is a protocol designed for
|
|
real clients and the clients themselves.
|
|
|
|
`schinst/` and `schfs-linux/` are scoped and unstarted, and are **frozen** -- see
|
|
[`docs/plan/1.0.md`](../docs/plan/1.0.md).
|