Initial commit: Schunix as it stands before the SchOS rename
An x86-64 operating system built from xv6, now largely rewritten: SMP, a copy-on-write root filesystem (SchFS), PCI/USB/virtio drivers, a TTF rasteriser, and a Linux-numbered syscall ABI. No history before this point -- the tree was never under version control. This commit exists so the rename that follows has something to undo to.
This commit is contained in:
commit
d0f7acf9eb
275 changed files with 51417 additions and 0 deletions
57
projects/README.md
Normal file
57
projects/README.md
Normal file
|
|
@ -0,0 +1,57 @@
|
|||
# projects/
|
||||
|
||||
Things that run **on** Schunix rather than things that **are** Schunix.
|
||||
|
||||
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 Schunix
|
||||
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/` | Schunix Compositor. Owns the display, composites clients, routes input. |
|
||||
| `schwm/` | Schunix Window Manager. Window placement, decoration, focus, on top of Schcom. |
|
||||
| `schde/` | Schunix 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 Schunix
|
||||
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/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.
|
||||
Loading…
Reference in a new issue