nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

docs: 1.0 is reached; Schcom stays; Linux's r8169 set ships

Browse source 
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
This commit is contained in:
Nexoniarz 2026-10-26 08:23:20 +01:00
commit 59aff881ac
21 changed files with 175 additions and 141 deletions
Download patch file Download diff file Expand all files Collapse all files

34
docs/plan/1.0.md
View file

@ -37,43 +37,31 @@ system lies about what it did.
### The acceptance test
One unattended run, asserted from the host, the way everything else here is tested.
When this passes, it is 1.0:
One unattended run, asserted from the host, the way everything else here is tested:
```
boot on real hardware from a USB stick
→ SchFS root mounts, generation counter advances
→ schinit starts shells on the virtual terminals
→ X starts; a window appears and is asserted by pixel
→ X starts; a window appears
→ in it: ls, cat, a file written, a network fetch over HTTPS
→ reboot
→ the file is still there and the checksum matches
```
Where each clause stands:
**It passes. 1.0 is reached.** Where each clause stands:
| Clause | State |
|---|---|
| boot from a USB stick on real hardware | **done** on an AMD B550 desktop, an ASUS TUF A15 laptop and an Ivy Bridge HP all-in-one |
| SchFS root, generation counter | **done** — the root is a SchFS image, in RAM when live |
| a terminal to type in | **done** — a shell on the first six of the twelve virtual terminals (`etc/schinit/*-shell.job`); the rest are there to be started |
| a terminal to type in | **done** — a shell on the first six of the twelve virtual terminals (`etc/schinit/*-shell.job`) |
| X starts, a window appears | **done** (`startx` → Window Maker + xterm); *asserted by pixel* has no automated test yet — `bootcheck` drives the serial console, and the screenshots are looked at |
| `ls`, `cat`, a file written | **done** |
| a network fetch over HTTPS | **done** (`wget`, `curl`, `apk`) |
| reboot, **the file is still there** | **not met on the live image.** The root lives in RAM and everything written is gone at reboot; SchFS is crash-safe on a disk, but nothing writes a disk root. This is the one clause that fails, and it is the open decision below |
### The one open decision
The acceptance test's last clause needs a root that survives a reboot. There are two honest ways to
close it, and which one is the owner's to choose:
1. **Write the installer** (`projects/schinst/`, [roadmap.md](roadmap.md) §5): partition a disk,
write the root, install the loader. Large, and until now frozen.
2. **Narrow the clause**: 1.0 is a *live* system, and the last line becomes "a file written to a
SchFS disk or partition that was attached survives a reboot" — which already works
(`make disk`, `make qemu` with `schfs.img`). Smaller, and it says what the system is.
Nothing else is on the path to 1.0.
The test used to end with *reboot — the file is still there*. That clause is **dropped**, deliberately: 1.0 is a **live**
system. The root lives in RAM and nothing written to it survives a reboot, and that is what the project is calling finished.
Persistence (an installer, or a persistent partition) is after 1.0, and its GUI is Schcom's job — see
[roadmap.md](roadmap.md) §5.
---
@ -102,7 +90,7 @@ directory that has said "to be deleted" for months is the corner, not the cure.
| | Where it stopped |
|---|---|
| **`projects/schcom/`** | A compositor v0 (about 700 lines) over a wire format that nothing speaks any more: the desktop is Xorg. It is the one thing in the tree that has ever put a client's pixels on screen by itself, and it has no consumer. **Delete it**, or say what it is for. |
| **`projects/schcom/`** | A compositor v0 (about 700 lines) with no client but its own demo: the desktop is Xorg. Kept on purpose — it is to draw the installer, and later SchDE ([roadmap.md](roadmap.md) §5) — but until that starts it is built and connected to nothing. |
| **The in-kernel LDLS window** | `vm.c` maps the kernel image a second time in the top 2 GB at every boot, and `include/ldls/ldls.h` describes a `/dev/ldls` loader — the start of loading Linux modules *into the kernel*, which [ldls.md](../architecture/ldls.md) rule 2 says is not how it is done. Nothing calls either. **Delete it**, or decide. |
| **`display_ops`** | `acquire` and `wait_vblank` are in the vtable, implemented by one driver at most, with no consumer: Xorg draws through `/dev/fb0`. Kept for the GPU work ([gpu.md](gpu.md)); that is the reason it stays. |
| **Socket activation** | `schinitd` parses `[Socket name]` and remembers the path. Nothing holds the socket. This is the entire reason for copying launchd, and it is the half that was not built. |
@ -141,7 +129,7 @@ Neither cancelled nor in progress. **Do not open these.**
| | |
|---|---|
| `projects/schinst/` | the installer, the installation environment, `.sip` (see the open decision above) |
| `projects/schinst/` | the installer, the installation environment, `.sip` — drawn by Schcom |
| `projects/schfs-linux/` | SchFS as a filesystem for Linux |
| [gpu.md](gpu.md) | amdgpu and nouveau through LDLS — measured, with the work it needs written down |
| [finch.md](finch.md) | Finch inside SchOS (the language itself is finished and lives in its own repository) |
@ -164,7 +152,7 @@ In order. **Do not start a gate before the one before it closes**, and closing m
| **1 — The foundations** | descriptor passing, a shareable memory object (`memfd`), `AF_UNIX` in the filesystem, dynamic linking, the event descriptors | **closed** — [kernel.md](../architecture/kernel.md), [networking.md](../architecture/networking.md) |
| **2 — Init as a role** | `schinit`, the supervisor, the heartbeat, PID 1 re-exec'd in place | **closed** — [init.md](../architecture/init.md) |
| **3 — The desktop** | Xorg on the framebuffer, Window Maker, a terminal | **closed** — [desktop.md](../architecture/desktop.md) |
| **4 — A root that survives a reboot** | the open decision above | **open** |
| **4 — A root that survives a reboot** | dropped from 1.0 by decision; it is the installer, after 1.0 | **not in 1.0** |
---

20
docs/plan/README.md
View file

@ -40,21 +40,21 @@ Plans leave this directory when they are done. These did, and what replaced them
And one that was **decided against**: `wayland.md`. Wayland needs DRM/KMS, libinput, udev and libseat, and DRM/KMS
alone is a kernel graphics subsystem. The desktop is X. The reasoning moved to [desktop.md](../architecture/desktop.md).
`SchWM` and `SchDE`, which were to be the window manager and the desktop on top of it, are gone from the tree: Window
Maker is the window manager, and a panel or launcher is an ordinary client.
`SchWM` and `SchDE` were removed from the tree as READMEs with no code: Schcom is its own window manager, and SchDE returns as
ordinary clients of Schcom when there is a Schcom to build them on. Meanwhile the window manager is Window Maker.
---
## The order
Set by [1.0.md](1.0.md), which is the authority. In short:
Set by [1.0.md](1.0.md), which is the authority. **1.0 is reached** (a live system; persistence is not part of it).
What is left before anything new starts:
1. **Close the one open gate**: decide what makes a root survive a reboot — the installer, or a narrower
definition of 1.0 (see *The one open decision* there).
2. **Empty the register.** Delete `projects/schcom/` and the unused in-kernel LDLS window, or say what they are for; build
socket activation or remove the key.
3. **Then**, and only then, whatever [roadmap.md](roadmap.md) says is next. GPU acceleration is the thing the laptop
wants most ([gpu.md](gpu.md)), and Finch inside SchOS is the thing the author wants next ([finch.md](finch.md)).
1. **Empty the register**: decide the unused in-kernel LDLS window (delete it, or use it), build socket activation
or remove the key, and give `projects/schcom/` its first client.
2. **Then**, whatever [roadmap.md](roadmap.md) says is next. The two things the owner wants most are the installer
drawn by Schcom — SchOS's own compositor, and the road to SchDE ([roadmap.md](roadmap.md) §5) — and GPU
acceleration on the laptop ([gpu.md](gpu.md)). Finch inside SchOS ([finch.md](finch.md)) comes after.
## What this plan does not address
@ -62,4 +62,4 @@ Stated here so it is not mistaken for covered:
- **No IOMMU**, so a driver in a process is isolated against its own bugs and not against a hostile driver.
- **No page cache**, so a general writable `MAP_SHARED` of a file is refused; `memfd` is the narrow answer.
- **No installer**, so nothing a live system writes survives a reboot.
- **No installer**, so nothing a live system writes survives a reboot — by decision, for 1.0.

21
docs/plan/roadmap.md
View file

@ -54,7 +54,24 @@ what is present ([boot.md](../architecture/boot.md)).
- **udev's job** — a uevent socket and `/sys/devices` — so X and others are told about devices instead of being
given a list.
## 5. The installer and `.sip`
## 5. Schcom, the installer, and SchDE
**Schcom** (`projects/schcom/`) is SchOS's own compositor. v0 is 715 lines that composite clients over a wire format of its
own, and everything it was blocked on in the kernel now exists: Unix sockets, descriptor passing, `memfd`, evdev, framebuffer
`mmap`. The plan is in three steps, each useful on its own:
1. **The installer's GUI is Schcom's first real client.** An installer wants a window, a list, a progress bar and a handful of
input events — small enough to be the program that forces Schcom's protocol to be real, and independent of Xorg, which is not in
the installation environment. It needs a wire format for clients that is designed (Wayland-shaped: surfaces, buffers shared by
descriptor, input events), not the v0 one.
2. **If that works, Schcom becomes useful in its own right**: window management as a module of the compositor (a compositor *is*
its window manager), multiple clients with focus and stacking, damage tracking.
3. **SchDE on top of it**: a panel, a launcher, a wallpaper and settings, as ordinary clients — only once there is a Schcom worth
putting them on. Until then the desktop is Xorg with Window Maker ([desktop.md](../architecture/desktop.md)).
Nothing here starts before [1.0.md](1.0.md)'s register is empty.
### The installer and `.sip`
Scoped in [`projects/schinst/README.md`](../../projects/schinst/README.md), which holds the detail. In short:
@ -79,7 +96,7 @@ Open questions, all wanting a decision before code:
now, or not?
- **Can the kernel mount a `.sip` read-only directly?** If it can, the installation environment's root can simply *be* the `.sip`.
The GUI for this is an X client, like everything else on the desktop.
The GUI for this is a Schcom client (above).
## 6. SchFS beyond SchOS