[Japabu]

Problem

The small-kernel track chose its steps from memory of what the kernel still holds. Nothing recorded, at a named revision, what kernel/src is made of, which of it the design gives to userland, or what is dead.

What this adds

Records only; no code changes.

A section, "What the kernel still holds", in issues/the-kernel-is-small-interrupts-post-and-threads-wait.md:

• kernel/src by responsibility at 9349705ce: 16 areas, files and tracked lines each (215 files, 55,378 lines), and whether the design keeps each. The crates the kernel links beside it are listed with their lines.
• What the design gives userland and the kernel still holds, each with its size, dependents, owner and what blocks it: arguments and environment (A child's arguments and environment are memory its parent lays out #1200), endowment labels, the TTY mark, the main thread's stack, what the loader named (partition GUIDs, boot sources and a device-path parser), the IGD OpRegion's lookup, the supervisor's last words.
• A ranked list of the next removals, labelled a proposal, with what must wait for A child's arguments and environment are memory its parent lays out #1200.
• Dead or stale code found on the way, recorded and not deleted.

Design changes, each inferred, kept apart from that table: the program's path (in the section), and three new findings the orchestrator resolves:

• issues/a-namespace-is-a-kernel-object-and-service-lookup-is-kept-out-of-the-kernel.md
• issues/the-kernel-stops-every-userland-thread-at-a-stop-the-supervisor-orders.md
• issues/the-kernel-decides-who-is-asked-to-quit-and-who-is-killed.md (the reviewer's candidate)

issues/x86-64-reads-the-cmos-for-a-wall-clock-the-loader-already-hands-it.md gains one observation: the clock uses the RTC's edges as a TSC reference, which bears on that defect's exit.

What a reviewer should weigh

1. The main finding is that little is left. The five ranked removals are about 435 lines of 55,378, 140 of them A child's arguments and environment are memory its parent lays out #1200's; with the OpRegion's lookup and the last words the table's rows are about 575. A larger reduction needs one of the design changes.
2. The area sums are a classification. Each file is counted once in the area of its main responsibility; the sums add to the total. The mapping is in the evidence below.
3. Sizes in the second table are estimates read off the functions, except A child's arguments and environment are memory its parent lays out #1200's, which is its own count.
4. The count differs from A child's arguments and environment are memory its parent lays out #1200's 55,386 by The loader boots the marked slot or nothing #1201 (+7 −15 in kernel/src), which landed between.
5. It is a section of the track, placed before "Standing" so it meets neither of A child's arguments and environment are memory its parent lays out #1200's hunks in that file.
6. The three design questions are kind: finding, status: open, each naming the orchestrator as who resolves it: issues/README.md reserves question for what only the owner may decide.

Review r1

All five blockers fixed as stated and every suggestion taken: the record cites the design and never the manual; the path is a design change and out of the ranking; one 64 KiB string stays charged while SYS_NAMESPACE_OPEN's name is unbounded; the CMOS points at its defect; FileType's file kinds are reused by the file protocol's clients, not dead.

Not done

• The stale text and dead code listed are not fixed, by the brief.
• kernel/CLAUDE.md's stale first caveat is recorded, not edited.
• The manual is unchanged: nothing here changes a design decision.

Checks

check	revision	target	result
cargo run -- --ci host	231d33b	macOS arm64	exit 1: 109 of 110 steps green. The red step is the build system, by llvm::tests::the_caller_s_environment_reaches_neither_the_build_nor_the_key alone (issues/the-llvm-environment-test-breaks-git-on-macos.md). log

Not repeated at the head: the commits since are wording in Markdown under issues/, three of them new files with the frontmatter issues/README.md requires, by the orchestrator's instruction for this round.

How the area table was counted: the rule file, every file with its area, the sums. No guest or metal run was needed or made.

🤖 Generated with Claude Code

[Japabu]

Review r1 of #1208 at f9186fb (base 9349705)

Verdict: SEND BACK. Five required corrections, all wording in the one Markdown file. The counting is sound and most of the inventory checks out against the code; the corrections are places where the record states something the tree or the manual contradicts.

Assessment

Records only: +109 lines in issues/the-kernel-is-small-interrupts-post-and-threads-wait.md, no production or test change. As a section of the existing track, placed before "Standing", it merges cleanly with #1200's two hunks in the same file (trial git merge-tree of f9186fb with 52ec105: no conflict).

The main finding holds: what is left in kernel/src that the design gives to userland is a few hundred lines, and larger reductions need design decisions. The inventory is worth having. Its value is accuracy, and it is not yet accurate in the places below.

What I verified

• Totals. git ls-files 'kernel/src/*.rs' at 9349705 is 215 files and 55,378 lines. I re-ran the evidence's area.awk over the tree: areas.tsv and files-by-area.tsv reproduce exactly, no file falls through to the ? rule, each file is counted once, and all 16 table rows match the sums.
• The 8-line difference from A child's arguments and environment are memory its parent lays out #1200's 55,386 is The loader boots the marked slot or nothing #1201 (dd73698), the one commit touching kernel/src between f9b5d7f and 9349705: +7 -15.
• Sibling crates. kernel/pure 49 files and 26,108 lines, pure/sched 15,570, proclife 3,550, pci 2,211, smmu 1,463, its 985, amdvi 902, sim 10,242, loom 6,088: all match.
• Classification sample. The six test-only files are each behind boot-actuators or test-actuators at their mod line. No virtio, ELF, AML, storage, network, audio, USB or input code is left in kernel/src beyond comments.
• Items present as described: endowment labels (three compared in kernel/src/loader/start.rs, three written for the supervisor in kernel/src/loader/mod.rs), the TTY mark and its four userland readers, the main stack's two constants, loaded.rs and its device-path parse, the OpRegion window, SYS_LOG_LAST_WORDS, namespaces, the CMOS driver (273 + 12 = 285) and its use as a TSC reference.
• Dead or stale items that hold: SYS_STACK_INFO has one in-tree caller (std_threads.rs); the rust fork at its pin and every lockfile have none. SYS_VM_DECOMMIT is called by mmap_stress and starveling alone. boot_partition_start_lba and boot_partition_blocks are read by one log line; wall_clock_* only by arch/aarch64/rtc.rs. The three stale texts are as described.
• Evidence. The log is of 231d33b on a macOS arm64 host, exit 1, one red step, by the test issues/the-llvm-environment-test-breaks-git-on-macos.md records; a one-file Markdown change cannot have caused it. The head differs by wording in that file with no frontmatter or issue-path change, so the result stands. The log is masked (<home>, <worktree>, <tmp>) and names no machine or person; its only model strings are the tree's own test names. The added section names no machine.

BLOCKERS

1. issues/the-kernel-is-small-interrupts-post-and-threads-wait.md:431 — FileType::File, Directory and Symlink are not dead. The record says they are "named by nothing in sdk, system, lib or apps". They are toyos_abi::syscall::FileType, and the SDK names all three: sdk/toyos/src/files/owner.rs:64,405-407,641, sdk/libc/src/posix_io.rs:255-257,518,521,587,647, sdk/std/sys/fs.rs:474-476. True half: no kernel path answers them. The accurate finding is that the file protocol's client reuses the kernel ABI's enum for answers the kernel never gives, which is a boundary question, not dead code.

2. :378 and :403 — the path is not "userland's, by the manual". The diagnostics page says a killed program "is reported as its file, offset and build id", and the kernel writes that report (record in kernel/src/process.rs). Nothing in the manual assigns the path elsewhere; the applications page only says the kernel resolves no path. Removing it changes that sentence, so it is a design change, yet the row carries no "(inferred)" label and ranks third. Move it out of this table or label it as a proposal that changes the design. Also, "after A child's arguments and environment are memory its parent lays out #1200 gives the process a name of its own" is not the dependency: on main the name already comes from argv[0], not the path (loader/mod.rs:167,252). The real blockers are the two the row names as unbuilt.

3. :427-430 and :403-405 — the path is not the last string at that bound. SYS_NAMESPACE_OPEN copies its name through user_str with no bound below MAX_USER_STR (kernel/src/syscall/dispatch.rs:404). So "after A child's arguments and environment are memory its parent lays out #1200 its path is the one string of that bound" is false, and removing the path does not release "the 132 KiB a thread is charged": one 64 KiB string remains until that name is bounded, and the page is the namespace names', which stay.

4. :390-393 and :416 — the CMOS already has a record, and this one contradicts it. issues/x86-64-reads-the-cmos-for-a-wall-clock-the-loader-already-hands-it.md is an open defect with an exit (x86-64 anchors on the loader's reading; arch/x86_64/rtc.rs deleted). The new text restates its fact without naming it, files it under "Kept by the manual's text" (line 350 of the same table says the manual names no CMOS driver) and says it needs "the owner before any is work". Name the file and drop the CMOS from the owner's list. The new observation, that clocksource.rs uses the RTC's edges as a reference, bears on that defect's exit and belongs there.

5. :334, 350, 369, 381, 383, 385-387, 415 — the record cites the manual. Root CLAUDE.md: "no code, comment, test or issue record cites it", and issues/README.md: the design is the manual's, "which a track does not restate". No record on main cites it; this section does in eight lines, by page ("the manual's kernel page", "the overview") and by paraphrase ("the manual says ..."). The table header's own phrasing, "Kept by the design", is the compliant form. If the brief intended an exception, that is the orchestrator's to say; as written the rule is broken.

SUGGESTIONS

• :414 — "about 590" reproduces from neither set: the six ranked items sum to about 475, the eight table rows to about 615. Say which rows are summed.
• :357-361 — kernel/copies (73 lines) is one of the "four under 200" but no kernel links it: it is kernel-copies, a host test that compiles arch/x86_64/copy.rs, as sim and loom are harnesses.
• :385-393, 416 — the remaining two second readings (namespaces, the stop's quiesce) are owed by the owner, and a track with status: open hides them from rg -l '^status: owner'. If they are to be asked, issues/README.md makes each a question file. Only namespaces is kept by the design's text; quiesce is merely unnamed.
• :381 — the loader-named row should weigh the boot design's other sentence: the loader hands the kernel a typed description of what it loaded and which slot it chose. The proposal (pass it on unread) is consistent with both, but "blocked on nothing" reads past it.
• :382 — the trust design names a firmware register window as a manifest-granted privilege, so the grant is kept; what is device-specific is the ASLS lookup. The row is already labelled inferred.
• :380 — the stack row under-claims: the memory design says thread stacks have caller-chosen sizes, which is direct support, not inference.
• :432 — the Stat remark could name issues/fstats-answer-is-declared-twice.md, which owns the two declarations.

Was anything the manual assigns to userland missed?

Nothing unambiguous. Two candidates, both my inference, neither required:

• The quit notice: the kernel walks the tree and asks or kills (object/notice.rs, quit_process in process.rs, kernel/proclife/src/quit.rs, 216 lines), while the authority design says quitting gracefully is the parent's job. The applications design calls interrupt, hang-up and terminate requests "native events", which reads the other way, so this is a second reading at most.
• Stale text not listed: UserImage's doc comment says "the file the kernel opened" (kernel/src/process.rs), and loaded.rs's header says it "interprets no path" above a function that parses one.

A note on SYS_STACK_INFO: an unconsumed checkout of the stacker fork has a ToyOS backend that calls stack_info. No lockfile in the tree names stacker, so the record's claim is true at this revision.

PR description (orchestrator's)

Item 4 can name #1201 as the 8 lines. Item 1's "about 590" inherits the sum above. "Dead or stale code found on the way" inherits blockers 1 and 3.

SEND BACK

[Japabu]

Orchestrator verification of r1's resolution at 89ead04 (records only, no code; verified by reading the diff from f9186fb):

1. FileType::File/Directory/Symlink are no longer called dead; the record says no kernel path answers them and the file clients reuse the ABI's enum.
2. The path is moved to "Changes of the design", labelled inferred, and out of the ranked order.
3. The per-thread string charge is no longer attributed to the path alone; SYS_NAMESPACE_OPEN's unbounded name is named.
4. The section points at the existing CMOS defect, and that record now carries the TSC-reference observation and its consequence for the exit.
5. No added line cites the manual.

Suggestions taken (sums state their rows: about 435 and about 575). The three design questions are separate finding records the orchestrator resolves. Only issues/ files change. Queueing.