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

49 lines
2.3 KiB
Markdown

---
name: schunix-devfs-procfs
description: "How /dev and /proc work in Schunix; ps and top work as of 2026-08-08"
metadata:
node_type: memory
type: project
originSessionId: a665e14b-86bd-4b41-a228-51377f3e9225
modified: 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.