A 64-bit operating system written from the metal up: SMP kernel, copy-on-write filesystem, Linux syscall ABI, Alpine packages, X11 on real hardware.
  • C 90.2%
  • Makefile 3.2%
  • PowerShell 2.3%
  • Shell 1.7%
  • Python 1.3%
  • Other 1.2%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Nexoniarz e72205cdc0 panic: the crash screen reaches every display, not just the console's
"it also doesn't show crash screen on virtio gpu or just other gpu than default
vga" -- true, and on the virtio-gpu it was worse than nothing. The head kept
showing the console from a second before the panic: one screen saying the
kernel is dead, the other showing a shell prompt.

panic() painted into the console framebuffer and stopped there. Two cases were
missing, and they are not the same problem.

**The kernel still drives it.** display_acquire() hands back a buffer; the
report is copied in and presented. Ordinary, and a no-op when the display
class's buffer *is* the console's, so a one-screen machine does not do the work
twice.

**A process drives it.** The hard one, and the one hybrid.md owed an answer
for. The kernel let go of the device deliberately, and the process holding it
will never run again -- there is no scheduling after a panic -- so there is
nobody left to ask. It is not a race that can be won by being careful.

So the userspace driver says where it is scanning out *in advance*:
PCIIOC_PANICFB, registered by vgpud after bring-up and after every modeset. On
a panic the kernel paints the report into that memory and asks the kernel
driver the device was taken from to put it on screen one last time --
`panic_present` in struct pci_driver, which virtio-gpu implements by resetting
the device out from under a driver that is still nominally running. That is
safe here and nowhere else, because nothing is going to run again.

The panic path allocates nothing. It cannot: a corrupted heap is one of the
ways a machine gets here, and an allocator that deadlocks takes the crash
screen *and* the serial log's last chance to be read. So the driver keeps its
BAR mappings across the handover, rebuilds one queue from 20 KB of static
memory, and bounds every spin -- including the reset acknowledge, which is an
unbounded `while` in probe() and correct there.

**The registration is checked like the promise it is.** The range must lie
inside a block that process got from PCIIOC_DMA on that device. Without that,
a claimed device would be a way to nominate any physical address in the machine
-- page tables, kernel text -- to be overwritten with four megabytes of crash
report at the one moment nothing is left to notice. That is a worse bug than
the one this fixes. It goes away with the claim and with the process.

What it buys is worth stating plainly: a device can be evicted to userspace
without the kernel losing its ability to tell you the machine died. The
alternative was a driver boundary that is also a blind spot.

Verified both ways under QEMU with two heads, `echo c > /proc/sysrq`, and a
screendump of each over QMP:

  vgpud holding the device   both heads byte-identical, serial says
                             "The report is on the virtio-gpu display too."
  kernel holding it          same, via display_acquire/display_present
                             (/proc/pci shows 1af4:1050 [virtio-gpu])

Both supported configurations: one boot each, no traps, no panics, socktest and
memfdtest green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-22 16:53:16 +02:00
.claude/memory zsh: one word in a cross-compile cache, and every $(...) hung 2026-09-22 00:29:39 +02:00
boot loader: the F8 menu on the serial line 2026-09-22 12:10:37 +02:00
cmd panic: the crash screen reaches every display, not just the console's 2026-09-22 16:53:16 +02:00
docs panic: the crash screen reaches every display, not just the console's 2026-09-22 16:53:16 +02:00
etc kbd: three layouts, and the arrow keys were sitting on top of UTF-8 2026-09-20 01:09:32 +02:00
include panic: the crash screen reaches every display, not just the console's 2026-09-22 16:53:16 +02:00
kernel panic: the crash screen reaches every display, not just the console's 2026-09-22 16:53:16 +02:00
ldls ldls: a second driver, and everything it found 2026-09-14 15:20:07 +02:00
lib unix: a bound socket is a file 2026-09-22 10:06:10 +02:00
ports zsh: two more cache answers that claimed capabilities SchOS lacks 2026-09-22 00:36:48 +02:00
projects freeze: one register for everything half-built, and the corners cleared 2026-09-13 20:28:05 +02:00
srv userland: 268 applets, an editor, names that resolve, and a web server 2026-09-14 19:24:55 +02:00
tools kmem: a slab allocator, and what the fixed tables actually cost 2026-09-22 09:32:06 +02:00
.gdbinit build: a gdb target, because the tree had no source-level debugger 2026-09-13 15:05:46 +02:00
.gitattributes Initial commit: Schunix as it stands before the SchOS rename 2026-08-09 13:47:01 +02:00
.gitignore kmem: a slab allocator, and what the fixed tables actually cost 2026-09-22 09:32:06 +02:00
LICENSE Rename Schunix to SchOS; the kernel becomes SchIFT 2026-08-09 14:09:59 +02:00
LICENSE.MIT Rename Schunix to SchOS; the kernel becomes SchIFT 2026-08-09 14:09:59 +02:00
Makefile vgpud: the second head shows the console, not a logo 2026-09-22 15:31:18 +02:00
NOTICE userland: 268 applets, an editor, names that resolve, and a web server 2026-09-14 19:24:55 +02:00
README.md userland: 268 applets, an editor, names that resolve, and a web server 2026-09-14 19:24:55 +02:00
run.ps1 boot/uefi: the system information panel, and the offset that faked a version 2026-08-11 10:52:43 +02:00
shell.nix build: a nix shell, because the loader is the one thing gcc cannot build 2026-09-12 18:31:34 +02:00

SchOS

A 64-bit operating system, written from the metal up.

SMP · copy-on-write filesystem · TCP/IP · PCI, USB and virtio drivers · TrueType text · Linux syscall ABI


SchOS began as xv6 and is now mostly something else. The scheduler, the memory manager and the trap path have been rewritten for x86-64 and for more than one processor; the filesystem has been replaced outright; the syscall table speaks Linux numbering so that real software — musl, toybox, mksh — runs unmodified.

It is a hobby system built by one person, and it is honest about that: what works below has been run, not inferred, and the gaps are listed as plainly as the features.

The pieces

Layer Name What it is
System SchOS The distribution — kernel, userland, tooling
Kernel SchIFT Multi-core x86-64 kernel with a modular VFS
Filesystem SchFS Transactional, copy-on-write, the root filesystem
API SchAPI System programming interface — the stable surface
Compositor SchCom Display compositor (planned)
Window manager SchWM (planned)
Desktop SchDE (planned)

uname -s reports SchIFT, the way every Unix reports its kernel rather than its distribution.

What works

Kernel — Long mode, 4-level paging, preemptive multitasking. SMP: one, two and four processors all boot, with CPU enumeration from the ACPI MADT rather than the 1994 MP table. Memory sized from the E820 map, so it runs in tens of megabytes rather than demanding hundreds.

Filesystem — SchFS is the root: a copy-on-write B-tree with a uberblock ring, so a crash leaves either the old tree or the new one and there is nothing to repair. Free space is derived from the tree rather than stored beside it, which removes a whole class of disagreement. /proc/schfs shows the generation counter advancing as writes commit.

Processes — fork, exec, wait, pipes, signals, sessions and process groups, mmap (anonymous and file-backed), POSIX shared memory, Unix domain sockets, poll.

Devices — PCI enumeration with a bus-agnostic device model at /proc/devices. Drivers for e1000 networking, virtio-gpu and stdvga displays, xHCI USB with HID, hub and mass-storage class drivers, IDE, PS/2, serial. /dev/fb0 speaks the Linux fbdev interface.

Networking — ARP, IPv4, ICMP, UDP, TCP and DHCP, on lwIP behind a driver-agnostic interface class. Verified end to end from the host, both directions, rather than by inspection. Names resolve, so wget http://host/ works; httpd serves a directory back the other way.

Userland — musl, toybox, mksh and zsh, built from source. 268 applets: ls, cat, ps, top, wc, cp, mount, awk, bc, diff and the rest behave the way you expect, because they are the real programs. edit is kilo — arrow keys, Ctrl-S, Ctrl-Q, nothing to learn.

Text — a TrueType rasteriser (glyf outlines, composite glyphs, cmap format 4) replacing the 8×16 cell grid. JetBrains Mono for the terminal, Roboto for the desktop layer to come.

When it dies — PSOGM, the Purple Screen of Guru Meditation: stop code, fault address, call chain, and a QR code containing a text copy of the whole report.

Quick start

make          # kernel + UEFI loader + root filesystem
make qemu     # build it and boot it
make iso      # a bootable ISO for VMware or real hardware

Builds on Linux, macOS, FreeBSD/OpenBSD/NetBSD and Windows (Git Bash). The toolchain is clang + lld everywhere — it is a cross-compiler by construction, so one LLVM install targets the bare-metal kernel, the 16-bit boot code and musl userland from any host. See docs/guides/building.md for prerequisites per platform, and docs/history/moving-to-linux.md for moving a checkout between machines.

Testing

Booting to a prompt proves nothing: a filesystem can mount and still fail the first real command, and that has happened here. So the test harness drives the serial console and asserts on what comes back.

tools/windows/bootcheck.ps1            # boot, run real commands, check the answers
tools/windows/bootcheck.ps1 -Tty -Ps   # terminal behaviour, process enumeration
make schfs-check                       # SchFS B-tree, object and image suites

bootcheck is PowerShell because pwsh runs on every supported host.

Layout

kernel/     arch/ core/ dev/ drivers/ fs/ net/ proc/ sys/
  fs/schfs/     the filesystem -- same source the host tools compile
include/    kernel and userland headers
boot/       uefi/ (PE loader)  common/ (shared loader UI)
lib/ cmd/   first-party userland runtime and programs
ports/      third-party software built from source
tools/      windows/ (.ps1)  posix/ (.sh)  python/ (.py)  and .c/.pl
docs/       architecture/ (what it is)  plan/ (what's next)
            guides/ (how to work on it)  history/ (why it's like this)

docs/README.md is the index. If you are reading the tree for the first time, docs/architecture/README.md is the system layer by layer.

One rule worth knowing: the kernel and the host tools compile the same SchFS source. mkschfs cannot disagree with the kernel about the on-disk format, because there is only one implementation — found and fixed on the host, where a test takes a second instead of a boot.

Another: syscalls are declared in exactly one place, kernel/sys/table.inc. Everything else is generated from it.

Not there yet

  • No desktop. Schcom composites and routes input; the plan is now to put it on Wayland and delete the homegrown protocol. See docs/plan/wayland.md.
  • No descriptor passing. No sendmsg/recvmsg, so no SCM_RIGHTS — which is what the GUI work stops at. docs/plan/foundations.md.
  • No dynamic linking. exec handles static ET_EXEC only.
  • No page cache, so writable MAP_SHARED of a file is refused rather than faked.
  • A USB disk cannot be booted from — the root device is compiled in rather than selectable.
  • SchFS has no Linux driver yet; the plan is on-disk format version first, then FUSE, then a kernel module.
  • CFF/OpenType outlines and TrueType hinting are deliberately out of scope.

Licensing

Apache-2.0, copyright Nexoniarz. See LICENSE.

The kernel derives from xv6, which is MIT — see LICENSE.MIT. Third-party code redistributed in a built image (musl, toybox, mksh, zsh, kilo, the fonts) keeps its own licence; NOTICE carries the attributions. All of it is permissive — there is no GPL in an image this builds, which is why the userland is toybox and not BusyBox and the editor is kilo and not nano. See docs/licensing.md.

Drivers may be adapted from BSD sources, which are compatible. Linux drivers are not: GPL-2.0-only and Apache-2.0 cannot be combined and redistributed. Reading Linux to understand hardware is fine; translating a driver is not. Best of all is the public specification — xHCI, virtio, AHCI, e1000 — which carries no licence on what you write from it.


Built with stubbornness and a serial console.