3182da3965
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.
45 lines
2.3 KiB
Markdown
45 lines
2.3 KiB
Markdown
---
|
|
name: schunix-rewrite-priorities
|
|
description: "The ordered list of what actually blocks Schunix, established by a full read of the kernel on 2026-08-01"
|
|
metadata:
|
|
node_type: memory
|
|
type: project
|
|
originSessionId: d1a1ea76-f919-411c-b0ef-0e1bc5064563
|
|
modified: 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]].
|