e04ca28812
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.
42 lines
1.8 KiB
Markdown
42 lines
1.8 KiB
Markdown
# Schcom — the SchOS Compositor
|
||
|
||
Owns the display. Every pixel that reaches the screen goes through it.
|
||
|
||
Clients do not draw to the framebuffer; they draw into their own buffers and
|
||
hand them over. Schcom decides what is on top of what, composites the result,
|
||
and presents it. It also owns input: it reads the raw event devices and sends
|
||
each event to whichever client should have it.
|
||
|
||
That is the whole job. Window *placement* is not part of it — that is SchWM's,
|
||
and Schcom exposes a protocol for it rather than implementing policy itself.
|
||
|
||
## Status
|
||
|
||
Not started. Scoped only.
|
||
|
||
## What it needs from the kernel first
|
||
|
||
| Need | State |
|
||
|---|---|
|
||
| Shared memory (`shmget`/`shmat`/`shmdt`) | done |
|
||
| `mmap` of `/dev/fb0` | done |
|
||
| Framebuffer geometry via the fbdev ioctls | done |
|
||
| **Unix domain sockets**, with `SCM_RIGHTS` | **missing** — `socket()` is a `NO_LINUX` stub |
|
||
| **Raw input events** — key down/up with modifiers | **missing** — input only arrives cooked, through the tty line discipline |
|
||
| Mode setting and double buffering | **missing** — needs the virtio-gpu driver |
|
||
|
||
The two marked missing are hard blockers, not inconveniences. A client and
|
||
the compositor have to pass a buffer handle between them, and a pipe cannot
|
||
carry one. And a compositor that reads the tty gets line-buffered text
|
||
delivered to a single foreground process, which is not input in any sense it
|
||
can use.
|
||
|
||
## Design notes, so far
|
||
|
||
- **Buffers are shared memory, not pipes.** A pipe means copying every frame;
|
||
at 800×600×32 that is 1.9 MB per frame per client. shm exists for this.
|
||
- **One protocol, versioned from the start.** SchWM and SchDE are separate
|
||
programs, so the protocol is a real compatibility surface from day one, not
|
||
after the fact.
|
||
- **Policy belongs to SchWM.** If Schcom starts deciding where windows go, the
|
||
split has already failed.
|