SchOS/.claude/memory/schunix-rewrite-priorities.md
Nexoniarz 3182da3965 Carry project memory in the repo, with tools/memory-sync.sh
Claude Code keeps per-project memory at <home>/.claude/projects/<key>/,
where <key> is the project's absolute path with every separator and the
drive colon turned into a dash. That makes it both rename-fragile and
machine-specific, and this project has hit each of those once:

  - D:\DEV\Schunix -> D:\DEV\SchOS changed the key, and 43 memories were
    invisible until moved across by hand.
  - Development happens from Windows and from Linux, and each looks in a
    different place for the same checkout.

Committing .claude/memory/ fixes both -- git carries it across renames
and between hosts -- and `import` puts it wherever the local machine
expects. .claude/settings.local.json stays ignored: those are per-machine
permissions.

The colon maps to a dash rather than being dropped. Deleting it gives
D-DEV-SchOS, which matches nothing and silently finds zero memories; that
was the first attempt. On Git Bash the key comes from `cygpath -w`,
because Claude Code is a Windows program and sees D:\DEV\SchOS, not
/d/DEV/SchOS.
2026-08-09 14:27:22 +02:00

2.3 KiB

name description metadata
schunix-rewrite-priorities The ordered list of what actually blocks Schunix, established by a full read of the kernel on 2026-08-01
node_type type originSessionId modified
memory project d1a1ea76-f919-411c-b0ef-0e1bc5064563 2026-08-01T19:01:25.126Z

Assessed the whole Schunix kernel (~12k hand-written lines) on 2026-08-01. Code quality is good; the problem is that xv6 lacks the concepts a real UNIX needs, so the fix is missing struct fields and subsystems, not bug fixing.

Order to work in (each item unblocks the next):

  1. struct proc fields. DONE 2026-08-01. xstate, killsig, pgid, sid, and uid/euid/suid + gid/egid/sgid added; exit() takes a wait(2)-encoded status; waitpid() reports it. Verified: sh -c "exit 42" yields rc=42, id prints uid=0(root). Also required coupling TIOCGPGRP to the real pgid — see schunix-tty-fg-pgrp-coupling.
  2. Signal delivery on the trap return path. Currently only fires on syscall return (kernel/sys/syscall.c), so a process spinning in userland never receives a signal.
  3. Fault-recoverable copy_from_user/copy_to_user with an exception table. uva2ka() returns a P2V alias valid for exactly one page; two separate historical crashes trace to that single design flaw.
  4. A page-fault handler. trap.c has no T_PGFLT case at all — hence no demand paging, no COW, no lazy stack growth.
  5. SCHFS directory format. Every directory is ≥113KB on disk, capped at 119KB; DIRSIZ is 14; dirent.inum is a ushort (65535-inode ceiling). Disk-format break, so decide before accumulating images worth keeping.
  6. Then the Ring 0A/0B split. Its own Phase 1 is "just file moves" — doing it before 1-5 means moving the same files twice.

Separately, a real confirmed bug: kernel/arch/x86_64/trapasm.S saves rax/rcx/rdx to three global scratch words (_sc_rax etc. in vm.c) with a comment claiming "IF is off, no race" — but the Makefile runs -smp 2, and cli only masks the local CPU. Two CPUs in syscall_entry clobber each other's saved user rip. Use per-CPU storage.

Also: KSTACKSIZE is 4096 (one page) on x86-64; Linux uses 16K. The stack canary exists because it really did overflow.

See schunix-linux-abi-decision, schunix-layout-migration.