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.
49 lines
2.3 KiB
Markdown
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.
|