Rename Schunix to SchOS; the kernel becomes SchIFT
Removes the "-unix" element and with it any trademark exposure to The
Open Group.
The split follows the ecosystem layout: SchOS is the system, and the
kernel has its own name. Kernel-identity strings are the only places
that take SchIFT -- uname(2) sysname, /proc/version, and the two licence
sentences that say "kernel" outright. That is what every Unix does here:
`uname -s` on Linux reports the kernel, not the distribution. Everything
a user reads as the product -- panic screen, boot menu, error prefixes,
docs, LICENSE, NOTICE -- is SchOS.
schunix.img is schos.img, the logo assets and the musl TLS patch are
renamed, and __SCHUNIX__ is __SCHOS__ (the define and the patch that
consumes it moved together).
Two things the rename broke, both found by the bootcheck suite:
- shmtest wrote "SCHUNIX-MMAP-OK" with a hardcoded length of 15 and
compared it back by hand-counted offsets (m[3]=='U', m[14]=='K').
The shorter marker left the write running two bytes past the literal
and the compare reading past the data, failing a file-backed mmap
that was working correctly. Now written and compared through one
constant with sizeof.
- bootcheck asserted a 31-byte file after appending to
"hello-from-schunix"; the shorter string makes it 29.
Both are the same mistake: a string literal whose length is written out
somewhere else. Full suite green -- base, Tty, Ps, Sock, Fb, Usb, Evdev.
This commit is contained in:
parent
d0f7acf9eb
commit
e04ca28812
83 changed files with 520 additions and 601 deletions
|
|
@ -1,6 +1,6 @@
|
|||
# projects/
|
||||
|
||||
Things that run **on** Schunix rather than things that **are** Schunix.
|
||||
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
|
||||
|
|
@ -11,7 +11,7 @@ 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
|
||||
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.
|
||||
|
|
@ -27,13 +27,13 @@ Concretely, code in 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. |
|
||||
| `schcom/` | SchOS Compositor. Owns the display, composites clients, routes input. |
|
||||
| `schwm/` | SchOS Window Manager. Window placement, decoration, focus, on top of Schcom. |
|
||||
| `schde/` | SchOS 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
|
||||
**`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
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Schcom — the Schunix Compositor
|
||||
# Schcom — the SchOS Compositor
|
||||
|
||||
Owns the display. Every pixel that reaches the screen goes through it.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# SchDE — the Schunix Desktop Environment
|
||||
# SchDE — the SchOS Desktop Environment
|
||||
|
||||
The parts you actually look at: a panel, a launcher, settings, a file
|
||||
manager, a terminal.
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# schinst — the installer, the installation environment, and `.sip`
|
||||
|
||||
Getting Schunix from an ISO onto a disk.
|
||||
Getting SchOS from an ISO onto a disk.
|
||||
|
||||
Three separate things live here:
|
||||
|
||||
1. **The installation environment.** A Schunix that boots from the ISO into a
|
||||
1. **The installation environment.** A SchOS that boots from the ISO into a
|
||||
known state with the installer running instead of a login shell. The ISO
|
||||
already boots to userspace without a hard disk (`make iso`), so this is a
|
||||
different init and a different root, not a different kernel.
|
||||
|
|
@ -17,7 +17,7 @@ Three separate things live here:
|
|||
|
||||
Not started. `.sip` needs its format written down before any code exists.
|
||||
|
||||
## `.sip` — Schunix Installation Package
|
||||
## `.sip` — SchOS Installation Package
|
||||
|
||||
The stated model is WIM, the image format Windows PE installs from, and the
|
||||
thing worth copying from WIM is that it is **file-based, not block-based**.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# SchWM — the Schunix Window Manager
|
||||
# SchWM — the SchOS Window Manager
|
||||
|
||||
Policy. Where windows go, which one has focus, what happens when you drag a
|
||||
title bar, how alt-tab behaves, what a window looks like at its edges.
|
||||
|
|
|
|||
Loading…
Reference in a new issue