SchOS/docs/plan
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Nexoniarz 113595f80b debugger: who owns this page, and who just wrote to it
docs/plan/debugger.md D3 and D4, which finish the plan apart from the
network transport.

D3 -- `whose <addr>`. The views each speak for one subsystem, which is what
keeps them cheap and current, and it is exactly why none of them can see
the bug that matters: a page on the DMA arena's free list looks fine from
dma.c, the same page on kalloc's free list looks fine from kalloc.c, and
that it is on both is a fact no single subsystem holds.

    # schdbg whose 0x3e239000
    phys 0x000000003e239000   kernel va 0xffff80003e239000
      dma     arena, handed out
      pcidma  slot 2, 0 KB into a 4000 KB block given to pid 4 (vgpud)
      mapped  pid 4 (vgpud) at 0x000000004000d000  rwu  vma[5] no_free

      consistent: 1 owner, 1 mapping(s)

Claimants register the way views do -- one line in the file that owns the
data -- so the kernel image, the log region, the arena, the page allocator,
the pciuser DMA blocks and every page table each answer for themselves.
`mapped` is the one no allocator can answer: there is no reverse map, so
vm_walk_user() goes forward over every mapped page of every live process.

Two verdicts are shouted and everything else is reported as fact. More than
one owner means the second allocator to hand the page out is handing out
memory the first is still using -- the H2 bug, which would have printed as
three lines. Free-but-still-mapped means a page will be given away from
under the page tables that point at it. Deliberately *not* a finding: no
owner at all, because kalloc keeps a free list and no record of what it has
handed out, so an ordinary allocated page has nobody to speak for it and
saying otherwise would be the query crying wolf.

D4 -- watchpoints, on the four debug registers that had been sitting unused
since this kernel was written. Armed against the same framebuffer page and
then killing the driver:

    watch 0: 0xffff80003e239000 written, 8 byte(s), by stosq+0x1f, pid 12 vgpud
             #0  memset+0xba
             #1  dma_alloc+0x2e2
             #2  do_dma+0x22a
             #3  pciuser_ioctl+0x13b
             #4  sys_ioctl+0x3c7
             #5  syscall+0xf6

The chain is the answer, not the rip. It reports and continues -- a data
watchpoint is a trap, delivered after the store completes, so returning
carries on with the program none the wiser, which is what lets this be used
on a machine that is still running.

Debug registers are per-CPU and there is no general IPI here, so the table
carries a generation number and each CPU reloads from its timer interrupt
when it notices the number has moved: one comparison per tick, one tick of
latency at worst. `watch` prints which CPUs have caught up, because "this
watchpoint is watching" and "this watchpoint is watching one CPU" must not
look the same.

Also fixed while testing: watch_init() was called from mpmain(), which runs
on every processor, so the command appeared in the list once per CPU.
dbg_register() now refuses a duplicate name outright, so the next init that
runs per-CPU fails loudly in the list rather than quietly doubling it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
2026-09-14 01:17:57 +02:00
..
1.0.md debugger: who owns this page, and who just wrote to it 2026-09-14 01:17:57 +02:00
debugger.md debugger: who owns this page, and who just wrote to it 2026-09-14 01:17:57 +02:00
foundations.md sockets: a descriptor can cross between processes 2026-09-13 19:49:37 +02:00
hybrid.md hybrid: the driver is killed, and the driver comes back 2026-09-14 00:05:43 +02:00
README.md debugger: who owns this page, and who just wrote to it 2026-09-14 01:17:57 +02:00
roadmap.md docs: the tree moved and the documentation did not 2026-09-13 20:05:06 +02:00
schapi.md freeze: one register for everything half-built, and the corners cleared 2026-09-13 20:28:05 +02:00
wayland.md freeze: one register for everything half-built, and the corners cleared 2026-09-13 20:28:05 +02:00

What happens next

Everything in this directory is unbuilt. When a piece of it is finished it leaves — deleted from here, rewritten as a description in ../architecture/. See the rule.

Read 1.0.md first.

It draws a finish line and puts most of the work below on the far side of it. Anything not named there is not being worked on, and the documents in this directory describe more than 1.0 contains.

It also holds the register of unfinished work, which is the one place anything half-built is listed. No new capability starts until that register is empty, and a row leaves it only by being finished or by being deleted from the tree.


The three current decisions

Taken together, because they turn out to need the same foundation.

wayland.md The GUI stack becomes Wayland. SchWM and SchDE are deleted — actually gone from the tree, not marked; Schcom survives and changes its wire format.
hybrid.md The kernel becomes hybrid — drivers move out into userspace processes, starting with the GPU. Partly built: all four mechanisms exist and the GPU driver already runs outside the kernel.
init.md Built. PID 1 is now a role the kernel refills; the description moved to ../architecture/init.md.

And the one they all wait on:

foundations.md Descriptor passing, shared memory, sockets in the filesystem. The critical path. Item 1 is built — sendmsg/recvmsg with SCM_RIGHTS.

And the one that says which parts of the above are actually being worked on:

1.0.md The finish line. Four gates, and everything else explicitly deferred.

And one that is a tool rather than a capability:

debugger.md A debugger for this kernel — one that observes rather than halts, and answers in this kernel's own vocabulary. Built, except the network transport: symbols, a log that outlives the kernel, /dev/dbg, the whose ownership query and hardware watchpoints are all described in ../architecture/debugging.md.

Two longer-horizon documents sit behind these: schapi.md, the API layering and the compatibility promise, and roadmap.md, which holds everything still open that is not one of the three above.


The order

Set by 1.0.md, which is the authority. In short:

0. Fix what is already wrong — first

Not a document of its own; it is Gate 0 of 1.0.md, assembled from the What it does not do sections in ../architecture/.

Before any new capability, and the reason is the one that put netdev_selftest() before the TCP/IP stack: a compositor built on a kernel with an unexplained hang and a socket layer that reports success for things it did not do will fail in ways indistinguishable from its own bugs.

1. foundations.md — the critical path

Both the Wayland work and the hybrid work stop here. Descriptor passing and shared memory are the substrate for handing a buffer to a compositor and for handing a device to a driver process. Doing it once for both is the entire reason these are one plan rather than three.

2. init.md — before the desktop, not after — done

A compositor being brought up for the first time crashes constantly, and something that restarts it and says why is worth far more during that work than at the end of it. Built; see ../architecture/init.md.

3. hybrid.md — moved up, and the reason is worth recording

This document used to put the hybrid work after 1.0, deliberately last, on this argument:

designing a userspace driver interface with no driver consuming it produces an interface that is wrong in ways nobody can see

The argument was sound and the conclusion drawn from it was wrong. What forced the change was the driver situation: SchOS cannot write a driver for every device that exists, no project can, and the only route to the hardware support an established OS has is a compatibility layer with the foreign drivers kept outside the kernel. That layer is this plan's mechanisms. It is not optional and it is not late work.

The original argument still holds, and it is answered rather than ignored: SchOS's own drivers are the consumers. vgpud is a real driver, with real requirements, and building the interface against it is what keeps it a general mechanism rather than a hole shaped like something foreign. The compositor is still a demanding consumer — it is no longer the only one available.

Four mechanisms, all built. One eviction done, one to go, then the foreign driver host.

4. wayland.md — with the GPU driver either side of the seam

W1–W3 and a terminal. W4 and W5 are post-1.0. Item 1 of foundations.md — descriptor passing — was the thing it could not start without, and it now exists.


In one sentence

Fix what is broken, build the descriptor-passing and shared-memory substrate, make init survivable, move the drivers out through an interface SchOS's own drivers have to live with first — and put a terminal on the screen.


What this plan does not address

Stated here so it is not mistaken for covered:

  • No IOMMU, so the hybrid work isolates against bugs and not against a hostile driver.
  • No page cache, so foundations.md delivers a memfd and not a general answer to shared file mappings. The general answer is still owed.
  • No garbage collector for descriptors in flight, so an AF_UNIX socket passed over itself and never received leaks. Bounded at thirty-two sockets, and nothing on this plan does it.
  • No dynamic linking, so no Mesa, no accelerated clients, and no third party shipping a .so for anything.
  • A new compatibility surface between PID 1 and PID 2, created by a plan whose own schapi.md §3 spends a section warning about those.
  • The three open networking items — getsockname, routing, and interrupt-driven receive — are untouched by any of this and still open. They are in roadmap.md.