proc: real CPU time, a tty number, and an exe that is a symlink

Four Gate 0 rows, and a fifth found while checking one of them.

**getrusage() did not distinguish RUSAGE_CHILDREN from RUSAGE_SELF**, which
undersells it: it ignored `who` entirely and reported the machine's *uptime*
as the caller's user time. Every process of every age answered with the same
number. Per-process CPU time is sampled at the timer tick now and split on the
interrupted privilege level; children's time is rolled up in wait() rather than
exit(), because RUSAGE_CHILDREN means *reaped* children and a running one has
not contributed yet.

**And wait4()'s fourth argument is a `struct rusage *` that was read off the
stack and thrown away.** That is the one shells actually use -- wait3() is the
same syscall with pid -1 -- so zsh's `time` reported

    16777216.01s user 1073.78s system 927983249% cpu

for every command. 2^24 seconds is uninitialised memory, and it did not vary
with the workload because it was never written. Now:

    busy loop   2.66s user  97% cpu   2.720 total
    sleep 2     0.02s user   0% cpu   2.248 total
    ls -lR /    0.70s user  65% cpu   1.070 total

**ru_stime is a structural zero and says so.** MSR_SFMASK includes FL_IF, so
SYSCALL clears interrupts and no tick can land while a process is inside a
syscall. Tick sampling cannot see kernel time at all here. Charging it needs
TSC deltas closed and reopened around every sched(), which is scheduler
accounting rather than sampling; the limitation is written down in
docs/architecture/kernel.md rather than papered over.

**/proc/<pid>/exe is a symlink.** It also needed a real st_size, and every
other procfs file deliberately reports zero -- readlink(2) bounds its copy by
it, so a symlink of size 0 resolves to the empty string, which looks like it
worked and is worse than the regular file was. Generating that one path in
ilock() costs one small render per stat() of one file.

**OVMF memory reporting is closed**: 1 GB reports 1017 MB usable, 2 GB reports
2041 MB. The firmware keeps about 7 MB either way, which is the right shape.

**And `ps` printed a header and nothing else**, which is not in any list
because nobody had run it. `ps` with no arguments shows only processes on
*this* terminal; /proc/<pid>/stat hardcoded tty_nr to 0, so nothing could ever
match. `ps -e` always worked, which is exactly what hid it. p->ctty was already
tracked -- procfs simply was not asked. Fields 14..17 were hardcoded zero too,
so TIME read 00:00:00 however long a process had run; they carry the new
counters now, and a shell that has burned 653 ticks reports 00:00:06.

Verified: utime climbs 18 -> 653 across a loop in the shell itself, `ps` lists
its own terminal, `ps -e` still lists everything, `readlink /proc/1/exe` gives
/bin/schinit, and sigtest/$()/rename/dmesg are all still green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/architecture/kernel.md

@@ -237,6 +237,14 @@ allocation over 8 MB mapped straight into a neighbouring live mapping.
 
 ## What it does not do
 
+- **`ru_stime` is effectively always zero.** CPU time is sampled at the timer
+  tick and split on the interrupted privilege level, but `MSR_SFMASK` includes
+  `FL_IF`, so `SYSCALL` clears interrupts and no tick can land while a process
+  is inside a syscall. User time is real and discriminates properly — a busy
+  loop reports 97%, `sleep 2` reports 0% — but kernel time needs TSC deltas
+  closed and reopened around every `sched()`, which is scheduler accounting
+  rather than sampling, and is not written.
+
 - **No slab allocator.** One page at a time, and every subsystem's fixed-size
   table is a consequence. This is the single change that would most improve the
   rest of the kernel.

docs/plan/1.0.md

@@ -215,12 +215,33 @@ right then.
       cross-compile cache. Autoconf's own default for that check is `yes`;
       omitting the line would have been right. See
       [../history/kernel.md](../history/kernel.md), section 7.
-- [ ] **`getrusage` does not distinguish `RUSAGE_CHILDREN`** from `RUSAGE_SELF`.
-- [ ] **`/proc/<pid>/exe` is a regular file, not a symlink**, so `readlink()`
-      fails and `ps -o comm` prints `[init]`. Symlinks themselves now work —
-      `open()` and `stat()` follow them, which they never did — so what is left
-      is procfs growing a symlink node type, not symlink support.
-- [ ] **OVMF memory reporting**, if the region-list fix did not fully close it.
+- [x] ~~**`getrusage` does not distinguish `RUSAGE_CHILDREN`** from
+      `RUSAGE_SELF`.~~ It did not distinguish anything: it ignored `who` and
+      reported the machine's *uptime* as the caller's user time, so every
+      process of every age answered with the same number. Per-process CPU time
+      is sampled at the timer tick now, children's time is rolled up on reap,
+      and `wait4()`'s fourth argument — a `struct rusage *` that was read off
+      the stack and thrown away — is filled. That last one is why zsh's `time`
+      reported `16777216.01s user` for everything: 2^24 seconds is
+      uninitialised memory, and it never varied because it was never written.
+      `time` now says 97% cpu for a busy loop and 0% for `sleep 2`.
+      `ru_stime` is a known zero; see
+      [../architecture/kernel.md](../architecture/kernel.md).
+- [x] ~~**`/proc/<pid>/exe` is a regular file, not a symlink.**~~
+      `lrwxrwxrwx ... exe -> /bin/schinit`, and `readlink` returns it. It also
+      needed a real `st_size`, which every other procfs file deliberately
+      reports as zero: `readlink(2)` bounds its copy by it, so a symlink of
+      size 0 resolves to the empty string — which looks like it worked and is
+      worse than the regular file was.
+- [x] ~~**OVMF memory reporting.**~~ The region-list fix did close it. 1 GB
+      reports 1017 MB usable, 2 GB reports 2041 MB, which is the right shape:
+      the firmware keeps about 7 MB either way.
+- [x] ~~**`ps` printed a header and nothing else.**~~ Found while checking the
+      `exe` fix. `ps` with no arguments shows only processes on *this*
+      terminal, and `/proc/<pid>/stat` hardcoded `tty_nr` to 0, so nothing
+      could ever match — `ps -e` always worked, which is what hid it. Fields
+      14-17 (utime/stime/cutime/cstime) were hardcoded zero too, so `TIME` was
+      `00:00:00` for everything however long it had run.
 
 **Work already done and not connected:**