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
SchOS/.claude/memory/schunix-devfs-procfs.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
Raw Blame History

name description metadata
schunix-devfs-procfs How /dev and /proc work in Schunix; ps and top work as of 2026-08-08
node_type type originSessionId modified
memory project a665e14b-86bd-4b41-a228-51377f3e9225 2026-08-08T16:24:48.813Z

/dev nodes are created by cmd/init/main.c with mknod() at every boot, and served by kernel/dev/cdev.c's devsw[major] table. Minor numbers under major 1 follow Linux's mem-major layout where free: null=2, zero=5, full=7, random=8, urandom=9. /dev/hole (minor 4) was deleted 2026-08-01 — an abandoned experiment nothing referenced.

/proc (kernel/dev/procfs.c, major 6) synthesises eight global files: meminfo, uptime, cpuinfo, version, stat, loadavg, mounts, filesystems. Each is a device node with its own minor; reading renders the whole text and returns the slice at the caller's offset.

Two gotchas that shaped it:

  1. devsw[].read() used to be called as read(ip, 1, addr, n) — every caller passed the literal 1 where an offset belongs, so a device could never know where a read started. Fine for a stream like the console, fatal for a /proc file: without an offset every read returns the whole text again and cat never terminates. kernel/fs/file.c now passes f->off and advances it by the amount returned.

  2. /proc/mounts must list / last. df keeps the last mount point that prefixes the path it was asked about, so listing root first made df / report /proc's numbers.

Per-process /proc/<pid>/ directories now exist and ps/top work — re-verified 2026-08-08 with tools/bootcheck.ps1 -Ps: ps finds init and the shell, -o ppid shows the real parent, top reads /proc/meminfo. This entry used to say they were impossible without a VFS rewrite; that was overtaken by kernel/fs/procfs.c, which implements /proc as a real filesystem behind struct fs_ops with synthetic inodes (pid<<8 encoding) rather than touching fs.c. See schfs-phase3-writes for the fs_ops dispatch.

One cosmetic gap remains: ps -o comm shows [init] in brackets, because toybox readlink()s /proc/<pid>/exe and ours is a regular file, not a symlink. Needs symlink support in procfs.

sysinfo(2) also reports real memory now (PHYSTOP and kalloc_free_bytes()); it used to return hardcoded 256MB/128MB, which is what free reads.