nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

Carry project memory in the repo, with tools/memory-sync.sh

Browse source 
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.
This commit is contained in:
Nexoniarz 2026-08-09 14:27:22 +02:00
commit 3182da3965
47 changed files with 2810 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

39
.claude/memory/schfs-v2-and-ramdisk.md Normal file
View file

@ -0,0 +1,39 @@
---
name: schfs-v2-and-ramdisk
description: The agreed SchFS direction and the ramdisk-root work completed 2026-08-01
metadata:
node_type: memory
type: project
originSessionId: d1a1ea76-f919-411c-b0ef-0e1bc5064563
modified: 2026-08-01T17:52:30.145Z
---
Agreed plan for Schunix's filesystem and installer, and step 1 is done.
**Order agreed 2026-08-01:** ramdisk root → `struct proc`/exit codes/pgrp →
SchFS → mkfs into `cmd/` → installer + framebuffer GUI.
**SchFS** keeps the name and is designed in `docs/architecture/schfs-v2.md`:
copy-on-write + checksum-in-parent-pointer + uberblock array (ZFS), one CoW
B-tree reused for every key type + extents with refcounts (btrfs), attribute
indexes for the "SQL-like" query feel (BeFS). Explicitly NOT doing: storage
pools/RAID-Z, online format conversion, dedup, or an actual query language —
the useful part of "database filesystem" is the index, not SQL. WinFS is the
cautionary tale; BeFS is the scale model.
**Done — ramdisk root.** `make ramroot` links a full SCHFS image into the
kernel and boots to a shell with no data disk attached (verified). Plain `make`
is unchanged. `kernel/dev/ramdisk.c` + a `bdevrw()` dispatcher in `bio.c`.
**Also done — `tools/mkfs` content dedup**, which is what made the ramdisk
practical: identical files now share one inode with real hard links
(`nlink > 1`). The 57 toybox applet copies collapsed from ~44 MB to one copy —
inodes 73 → 19, used blocks ~47,000 → ~3,400. `mkfs` also gained `--size
<blocks>` so one tool builds both the big root image and the small ramdisk one.
**Why it is opt-in:** stage2 loads the kernel by PIO one sector at a time, so a
6 MB ramroot kernel is visibly slower to boot than the 350 KB default. Use
`make ramroot`, never `make RAMROOT=1` — the flag changes CFLAGS, which make
cannot see, so stale objects would silently keep the wrong `ROOTDEV`.
See [[schunix-rewrite-priorities]], [[schunix-build-environment]].