Repository navigation
The loader lock takes the per-range maxima and its profile strips debuginfo, the last alignment of the one-workspace track - #738
Merged
Merged
Conversation
…carry `bootloader/Cargo.lock` moves each of its 8 registry crates that sat below the highest version another of the five main locks carries in the same semver range up to that version: bitflags 2.4.2 -> 2.11.0, cfg-if 1.0.0 -> 1.0.4, libc 0.2.189 -> 0.2.190, log 0.4.20 -> 0.4.29, unicode-ident 1.0.12 -> 1.0.24, proc-macro2 1.0.78 -> 1.0.106, quote 1.0.35 -> 1.0.45 and syn 2.0.48 -> 2.0.117. One `cargo update -p <name>@<old> --precise <new>` per crate, the proc-macro chain leaf first. Every version it gains is one the root lock already carries, with the same checksum; nothing enters or leaves the lock, and no manifest changes. This is the last alignment of the one-workspace track (issues/the-tree-resolves-in-five-cargo-locks-not-one.md): after it no registry pair of the five locks sits below its range's maximum. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WcU2Dsw6mDYtwYfzVHPzM8
`[profile.toyos]` in `bootloader/Cargo.toml` gains `strip = "debuginfo"`, the one key in which it differed from the kernel's and userland's. The one workspace the track merges the five resolutions into has one profile, and the track (issues/the-tree-resolves-in-five-cargo-locks-not-one.md) has this change, which moves the loader's bytes, land before the merge so that the merge itself moves none. On this target the key strips nothing: rustc's MSVC-flavour linker ignores `-C strip` (`MsvcLinker::debuginfo`), and the loader's link already writes no debug information (`/DEBUG:NONE` in `bootloader/.cargo/config.toml`). It enters the profile, and with it every unit's metadata hash, so the loader's bytes move; the pull request measures by how much, and in which crates' code. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WcU2Dsw6mDYtwYfzVHPzM8
No registry pair of the five locks now sits below its range's maximum, and the loader's `[profile.toyos]` carries the `strip` the kernel's and userland's do. The track's counting paragraph says so; its exit records the third alignment beside #724 and #732; the constraint naming the loader's missing `strip`, and the sentence leaving unmeasured what the loader's `libc` pulls with it (nothing: it is a leaf, and the lock gained no entry), are gone. "Four of them declare their own `[profile.toyos]`" becomes three: the root's went with toyos-ld in #726. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WcU2Dsw6mDYtwYfzVHPzM8
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WcU2Dsw6mDYtwYfzVHPzM8
Collaborator
Author
Evidence (1 of 3): the alignment, the checksums, the pair counts and what the moved crates reachEvery script is shown as it ran and was not edited after; every log is its whole output, by Provenance: Named so nothing in the directory is unaccounted for:
|
Collaborator
Author
Evidence (2 of 3): the bytes, with the negative control, and which crates' code movedSame rules as comment 1. How the maps are got without moving a byte.
|
Collaborator
Author
Evidence (3 of 3): the gates, the T14 staging, and the staged images' loaderSame rules as comment 1.
|
Collaborator
Author
Evidence (4): why the strip line moves the layoutSame rules as comment 1.
|
Collaborator
Author
|
Full Drive-mode T14 suite at |
Collaborator
Author
Review, round 1, head
|
Japabu
marked this pull request as ready for review
October 4, 2026 22:06
Japabu
enabled auto-merge
October 4, 2026 22:06
Japabu
added a commit
that referenced
this pull request
Oct 4, 2026
Conflicts against #728: - toyos-logstream: #728's `program_ms` read the old `{…}` program head through `shown()`, both gone here. Folded into `parse`: the counters judge reads `parse(l).and_then(|p| p.ms)`, one reader for every line; its readback test now asserts `parse` on every head `ProgramLine` writes. - console: #728's `logkeeper_api::read()` kept, with this branch's `asked_ms` on `stamp_ns()`. Semantic conflict: #728's idle-second check compared `counters_metal`'s `at`, read off `nanos_since_boot()` (the kernel clock's zero), with line stamps that count from the counter's zero here. `counters_metal` now reads `stamp_ns()` for `at`; the SMI span `at2 - at0` is a difference and unaffected. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WcU2Dsw6mDYtwYfzVHPzM8
Japabu
added a commit
that referenced
this pull request
Oct 4, 2026
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WcU2Dsw6mDYtwYfzVHPzM8
Japabu
added a commit
that referenced
this pull request
Oct 8, 2026
…ts two stages landed `issues/the-tree-resolves-in-five-cargo-locks-not-one.md` named one thing left, the T14's run of the metal profile on the folded build. It ran green at `db55db96a`, and the review ruled no boot owed for what followed, so the exit is met and the file goes. Stages 2 and 3 of `issues/the-tree-says-who-uses-each-thing.md` cited it: the alignments landed in #724, #732 and #738, the workspace in #746. What the file carried that is still true is at its site: the root manifest's `exclude` says why `userland/libc` and the guest test crates keep their own resolution. Two facts go with the file. libc's lock resolves `toyos`, `toyos-abi`, `toyos-elf`, `toyos-osrelease` and `dlmalloc` a second time and nothing holds it to the root's; both carry `dlmalloc` 0.2.13. `Cargo.lock` carries `miniz_oxide` 0.8.9 for `png` 0.18.1 beside 0.9.1 for `flate2` 1.1.10 until `png` takes 0.9. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RvnWQFcMuGqTHYhvSnTe8A
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Oct 8, 2026
…nd the SDK resolve together (#746) Stage 3 of `issues/the-tree-says-who-uses-each-thing.md`. The root, `kernel/`, `bootloader/`, `userland/` and `toyos/` were five Cargo resolutions; they are one workspace with one `Cargo.lock`, one `[profile.toyos]`, one `[patch]` table and one tracked `.cargo/config.toml`. No directory moves. Head `dd12c0b32`, on `origin/main` `6f87cdb9c` (#749; none of #757, #759 or #762 had landed when it was merged and measured). It is `9ef866436`, where the CI readings of the fold itself were taken, plus two merges of `main` and the close of the stage's issue. Everything owed at the merged head is in the next section, measured at `dd12c0b32`. ## The merge of #749, measured at `dd12c0b32` #749 wrote its new dependency edges into `kernel/Cargo.lock` and `userland/Cargo.lock`, which this branch deletes. Both modify/delete conflicts are resolved by deleting the file and re-resolving the root lock. Git merged the root `Cargo.lock` without a conflict into a lock that is wrong, as the review found: `cargo metadata --locked` on it exits 101 (`cannot update the lock file … because --locked was passed`). It had `toyos-userbound`'s edges to `toyos-abi` and `toyos-bootmap`, which #749 also wrote into the root lock, and not `acpiserver`'s to `toyos-acpi` and `toyos-aml`, which #749 wrote into userland's alone. `cargo metadata --offline` re-resolved it. `diff` of git's merged lock against the re-resolved one is those two lines under `acpiserver` and nothing else: no package added, no version moved. | Owed | Command | Result | |---|---|---| | The lock resolves as committed | `cargo metadata --locked --format-version 1` | exit 0 at this head by the host suite's step "the licences of what ships", which runs `cargo metadata --locked` for every shipped crate's manifest and is green in `host.log` and in run 37757675374; the hand run's empty stderr (`metadata-locked.err`) predates the merge commit and recorded no exit | | The lock's (name, version) pairs are the union of `main`'s five | `pairs.sh <worktree> 6f87cdb`: the pairs of `Cargo.lock`, `kernel/`, `bootloader/`, `userland/` and `toyos/Cargo.lock` at `6f87cdb9c`, `sort -u`, against the root lock's | 692 against 692, `diff` exit 0 (`pairs.out`) | | The folded kernel and loader are the control's bytes | `prove.sh 6f87cdb dd12c0b …`, the round 3 script unchanged | exit 0; all four `control vs fold` byte rows `cmp` exit 0; every row in "The checks" below (`prove.out`) | | No new reader of a compiled-in path | `git diff -U0 e3bdff8 dd12c0b -- tests src toyos-blackbox toyos-symbols userland/symbolize`, its added lines searched for `\.rs`, `taken at`, `panicked at`, `Location`, `file()`, `PREVIOUS_PANIC`, `strip_prefix`, `src/`, `pure/` | the merge touches five files there, all under `tests/`; 13 hits, of which 4 are diff headers and 9 the field `info.rsdp`; none reads a path. `tests/common/power.rs:429` is still the one reader outside fixtures, and reads `taken at kernel/src/hardlockup/probe.rs` (`readers-merge.diff`, `readers-hits.txt`) | | `cargo run -- --ci host`, once, on the development machine | at `dd12c0b32`, `cargo run -- --ci host > host.log 2>&1; echo EXIT=$?` | exit 0; the log ends `[ci] Host: 77 step(s), all green`; 1-minute load 26.60 when it started (`host.log`) | The logs are in the round's scratch directory (`orch/oneworkspace-r4/`), which a reader of this pull request cannot reach; `prove.out` and `pairs.sh` are in the round 4 comment. ## What changed, per decision - **Members.** `kernel`, `bootloader`, `toyos` and userland's 40 packages join the root `[workspace]`. `userland/Cargo.toml`, four locks, three `rust-toolchain.toml` and three per-directory `.cargo/config.toml` are deleted. The toolchain files chose nothing the build read: every guest `cargo` already runs under `RUSTUP_TOOLCHAIN` naming its sysroot. - **Flags.** `build.target` is gone, since every guest build already passes `--target`. The root config holds one `[target.<triple>]` table per guest triple, six, each with the flags its directory's config gave it. A host build takes none, as before. Two things do change: - The guest crates outside the workspace that are built from their own directory for a ToyOS triple (`tests/toyos-rust-tests` and its `tls-*` crates) now take `-Dwarnings`, because cargo reads the tracked root config from above them. On a checkout without a local config they took no flags. - The one build that sets `RUSTFLAGS` itself (the test binaries linked against a `cdylib`, `src/build.rs`) takes none of the table: the variable replaces it. - **Profiles.** The root's `[profile.dev]` is `opt-level = 2`. The kernel library's host tests, its model controls, the SDK's tests and every surveyed userland crate's host tests used to resolve in their own workspaces and ran at `opt-level = 0`; they now run at 2. - **What stays apart** (the root manifest's `exclude` says why at each entry): `rust/`; `tests/toyos-rust-tests` and its `tls-*` crates and `tests/ssh-client-host`, because `[patch]` is workspace-wide and they patch or refuse what the root patches; and `userland/libc`. libc keeps its own lock because that lock is an input of the sysroot key: as a member it would be resolved by the root lock, and every dependency change of any member would move the key and rebuild every sysroot. The price is a sixth resolution of `toyos`, `toyos-abi`, `toyos-elf`, `toyos-osrelease` and `dlmalloc` that nothing holds to the root's (both carry `dlmalloc` 0.2.13 today). - **The lock** is every `[[package]]` of the five locks, deduplicated and resolved by `cargo metadata`. Nothing was `cargo update`d. Since the lock reviewed at `88bcbf4d3` it has changed by #749's four edges alone (see the section above); `cargo metadata --locked` exits 0 at this head. - **One target directory.** Every guest is built at the root with `-p` into `target/`. A stale sysroot used to `cargo clean` a crate's own target; that would now empty the build system's own, so `Stale::All` removes `target/toyos` and the guest triples' directories instead, and the `cargo clean` path, its member assertion and its test are deleted. - **Kernel and loader build one after the other.** They were built on two threads. In one target directory cargo serialises them anyway (measured in round 1: the second prints `Blocking waiting for file lock on artifact directory`), so the thread scope is deleted. - **The host suite** can no longer be `--workspace`: the kernel binary, the loader and most of userland do not build for a host. `src/hostws.rs` says which members a host tests, and the workspace test and clippy runs `--exclude` the rest by package name. - **Fork clones.** The tracked config includes the gitignored `.cargo/local.toml` when it exists, and `implementer.md` names it. - **The merge of #745.** `src/sysroot.rs` keeps both sides: `SYSROOT_SOURCES` carries `"sdk/std"` and `SYSROOT_MANIFESTS` ends in `".cargo/config.toml"`; its test keeps both loops; `issues/toyos-has-its-own-allocator.md` keeps `sdk/std/sys/alloc.rs` and "from the kernel's graph in `Cargo.lock`". Git merged all three without a conflict. - **The host's own apps build where the userland tests build.** `src/ci.rs`'s apps step passes `--target` only where it checks another host's triple. On `main` the `userland/*` test steps and the host's apps step both named the host triple and shared `userland/target/<host triple>`. The fold took `--target` off the test steps, which no longer need it to keep a guest triple out, and left it on the apps step: the tests filled `target/debug`, the apps `target/<host triple>`, and every dependency was compiled twice. That is what made the sealed tree larger than `main`'s (see CI). - **The merges of `main`.** #747, #748, #750, #751, #753 and #755 merged without a conflict. #749 did not: see the section above. - **The merge of #752.** Git merged it without a conflict: both workflows' `host` jobs keep `CARGO_PROFILE_DEV_DEBUG: line-tables-only` in `env:`, and `carry()` no longer sets it. No manifest and no lock moved in the merge. - **Issues.** `issues/the-tree-resolves-in-five-cargo-locks-not-one.md` is deleted: the one thing it named as left, the T14's run of the metal profile on the folded build, ran green at `db55db96a`, and review round 2 ruled no boot owed for what followed on two conditions, both in the section above. Stages 2 and 3 of `issues/the-tree-says-who-uses-each-thing.md` now read "Landed in #724, #732 and #738" and "Landed in #746". What the file carried that stays true is the root manifest's `exclude`, which says why each excluded directory keeps its own resolution; the deleting commit's message carries the rest (libc's second resolution of five crates, and `miniz_oxide` 0.8.9 beside 0.9.1 until `png` takes 0.9). `issues/cargo-run-inside-kernel-loom-or-kernel-sim-builds-for-a-bare-target.md` is closed on the two in-directory runs at `9ef866436`. `issues/the-sdk-is-linted-by-no-clippy-run.md` is filed and names its owner, the build system. ## The fold changed the kernel's source paths, and the proof did not see it The T14's run of the whole metal profile at `88bcbf4d3` exited 1: 295 passed, 1 failed, 30 boots. The red row was `hard_lockup_ends_a_deaf_cpu`. Its judge looked for `taken at src/hardlockup/probe.rs` in the previous boot's panic record, and the readback's loader log says `taken at kernel/src/hardlockup/probe.rs:145:29`. **What changed in the kernel's strings.** Cargo hands rustc a workspace member's source by its path from the workspace root, and rustc writes that path into every panic and `Location`. The kernel's root was `kernel/`; it is now the repository. So `src/...` became `kernel/src/...`, and a path dependency outside the old root, which the base named by the checkout's absolute path, is now named from the repository root (`toyos-abi/src/...`). Read from the actuator kernel staged at this head: 254 distinct `.rs` paths, 158 under `kernel/`, 38 under a `toyos-*` crate or `bcachefs`, none bare `src/` or `pure/`, none naming the worktree. **Why the proof did not see it.** Both of its oracles were blind to it by construction: - The byte row compared the fold against a control that is the base with its workspace root moved up. The control moved the root too, so it carries the same new paths and the bytes agree. - The `rustc`-lines row compared base against fold after a `sed` that rewrites `(kernel/|bootloader/)?(src|pure)/x.rs` and `ROOT/<crate>/src/lib.rs` to one form. That rewrite is needed, or every path crate's line differs and the row can show nothing else; but it absorbed the change without reporting it. `prove.sh` now reports what that rewrite absorbs: per artifact, how many crates' source arguments were renamed, and a diff of the `.rs` paths the artifact carries, base against fold and control against fold. The script is in the round 3 comment and has run twice since, at `9ef866436` and at this head. **Every reader of a compiled-in path.** I searched the harness, the guest tests, the build system, `toyos-blackbox`, `toyos-symbols`, `userland/symbolize`, the loader and the kernel's panic path for path literals, prefix strips and `Location` readers. One reader matches a compiled-in path by its prefix: `tests/common/power.rs`, the red row's judge, now fixed to the path the kernel records. Everything else is prefix-blind (`panicked at`, a file name with its line) or a synthetic fixture. The kernel's panic slot keeps the last 96 bytes of a path; the longest kernel path is 46, so nothing is cut. Userland's panic sites gain a `userland/` prefix the same way; no test reads one. **The record rows.** The judging asked to record three `boot.testcases-bounds.*` rows. They are not this change's: that boot was already staged on the base and unrecorded, and `main` recorded it in #745. They arrive with the merge and nothing is committed here. ## What the fold changes in what is built The lock row was measured at `dd12c0b32` against `6f87cdb9c`, the `rustc` row by `prove.sh` at the same pair; the two `cargo tree` rows at `88bcbf4d3`, and were not taken again. | Measured | Result | |---|---| | Lock: (name, version) pairs, the fold's against the union of `origin/main`'s five | identical, 692 pairs, `diff` exit 0 | | Lock: sources | registry `getrandom` 0.2.17, 0.3.4, 0.4.2 are gone; the forks at the same versions remain | | Kernel and loader, both arches: every `rustc` command line of `cargo build -v`, base against fold, path and cargo's path-derived hashes taken out | identical, `diff` exit 0: 31 units per kernel, 55 and 37 per loader | | Userland, both triples: `cargo tree -e features` over every program, base against fold | identical, `cmp` exit 0 | | Host members: the same | `diff` exit 1, on `getrandom`'s source alone | So one resolved crate changes: the build system and the other host members compile the ToyOS forks of `getrandom` 0.2.17, 0.3.4 and 0.4.2 instead of the registry's, same versions, same features. And every source path compiled into the kernel and the loader changes, as above. ## The checks (high-risk: build system) Measured at `dd12c0b32` against `origin/main` `6f87cdb9c` by `prove.sh` (the script of the round 3 comment, unchanged), exit 0; its output is in the round 4 comment. Round 3 measured the same rows at `9ef866436` against `b432ed21c`, round 1 at `88bcbf4d3` against `e7010129f`. **Negative control.** The whole change reverted is the base. A second control is the base with only its workspace root moved up, keeping the crate's own base lock and its profile. It is given the fold's root `.cargo/config.toml`, so the control does not hold the flags: the one row that does is base against fold on normalised `rustc` lines. **Oracle.** Bytes and cargo's own command lines. Each cell is its own `cmp` or `diff` exit: | | kernel x86_64 | kernel AArch64 | loader x86_64 | loader AArch64 | |---|---|---|---|---| | control vs fold, bytes | 0 | 0 | 0 | 0 | | fold vs fold rebuilt, bytes | 0 | 0 | 0 | 0 | | base vs fold, bytes | 1 | 1 | 1 | 1 | | base vs fold, `rustc` lines normalised | 0 | 0 | 0 | 0 | | control vs fold, `rustc` lines verbatim | 0 | 0 | 0 | 0 | What the normalisation absorbs, reported by the three `paths` rows: base against fold, cargo hands rustc another source path for 29 of 31 crates of each kernel and for 35 of 50 and 13 of 35 crates of the loaders (`diff` exit 1 each, as expected); the `.rs` paths the x86-64 kernel carries are 250 on both sides, of which the base has 39 under the tree's absolute path and 150 from the crate's own root and the fold none of either (`diff` exit 1); control against fold the artifacts' paths are identical (`diff` exit 0, all four). **Mutations**, each on a fresh copy of the fold: M1 (drop the `[target.x86_64-unknown-uefi]` table) loader build exit 101; M2 (lock `dlmalloc` at 0.2.12) `cmp` exit 1 and lines `diff` exit 1; M3 (select `bcachefs` beside the kernel in one `cargo`) kernel build exit 101. ## Gates The rows of the section "The merge of #749" were read at `dd12c0b32`. Every row below was read at `9ef866436` unless it says otherwise, each once, the narrowest that judges it. `ci.yml` runs on the push of `dd12c0b32`; its result is not in this body. | Gate | Result | |---|---| | `cargo run -- --ci host` | at `dd12c0b32`, development machine: exit 0, `[ci] Host: 77 step(s), all green`. Linux runner at `9ef866436`: `ci.yml` run 37740454881 `host` success; cold inside `--ci seal`, nightly run 37740449787: `[ci] Seal: 80 step(s), all green`; on macOS, the same nightly's `portability-macos`: success | | `cargo test --lib ci::tests` (the changed step's own test) | exit 0, 13 passed | | The images and the guest suite | at `9ef866436`, run 37740454881: `toolchain / build` and `guest / suite` success (KVM); run 37740449787: `toolchain / build` and `tcg / suite` success. At `e3bdff8af`, run 37755369755: `host` and `toolchain / build` success, `guest / suite` still running when read. Not run locally, and not read at `dd12c0b32` | | `prove.sh 6f87cdb dd12c0b …` | exit 0; every row as in the table above | | `cargo test` inside `kernel/loom` | exit 0 | | `cargo test` inside `kernel/sim` | exit 0 | | Cold wall clock, x86-64 kernel and loader (`wall.sh`, one run) | base, two cargos side by side: 24 s, 1-minute load 34.92 before it. Fold, one after the other: 20 s, load 42.23. Other agents' builds were running, so the two are not a controlled pair; the fold was not slower | | Metal profile | every row green at `db55db96a` (comment 6048782042). Since then the branch changed `src/ci.rs` and the root lock's two `acpiserver` edges; the kernel sources that moved are `main`'s own landings (#747, #748, #749), merged in. Review round 2, ruling (3), owes no boot for the merge of #749 on two conditions, both met above | | `cargo test --manifest-path userland/acpiserver/aml/Cargo.toml` at `e3bdff8af` | exit 0 | | `git status --porcelain --ignore-submodules=none` at `dd12c0b32` | empty | `issues/cargo-run-inside-kernel-loom-or-kernel-sim-builds-for-a-bare-target.md`'s close now stands on the two in-directory runs at `9ef866436`. The logs of these rows are files in the scratch directory of the round that took them (`orch/oneworkspace-r3/`), which a reader of this pull request cannot reach; the proof's and the measurements' outputs are in the round 3 comment. ## CI **Why the sealed tree was larger than `main`'s, measured.** A `workflow_dispatch` of `nightly.yml` at `88bcbf4d3` (run 37685714260) sealed `9348536345 B in 20064 files`, red. Units compiled per step, counted from that log and from `main`'s nightly at `b432ed21c` (run 37717000719, sealed `18708 files, 7664839895 B`): | step | `88bcbf4d3` | `main` | |---|---|---| | the driver's own build | 203 | 203 | | the build system | 207 | 207 | | the workspace's host members | 99 | 99 | | clippy, warnings denied | 412 | 417 | | the controls | 56 | 56 | | `userland/*` | 225 | 289 | | the apps for linux | 282 | 47 | | the apps for macos | 248 | 248 | | the apps for windows | 239 | 239 | Of the 256 distinct crates the apps-for-linux step compiled at `88bcbf4d3`, 226 had been compiled by an earlier step of the same run; 30 by none. The cause is the target directory: the test steps built without `--target` into `target/debug`, the apps step with `--target x86_64-unknown-linux-gnu` into `target/x86_64-unknown-linux-gnu`. Profile, features and `RUSTFLAGS` are the same in both. **The fix, measured once on the development machine** (`share.sh` in the round 3 comment; cold, a target of its own, `aarch64-apple-darwin`): after the fourteen test steps' builds (271 units), the ten apps with `--target <host>` compile 270 units and add 616,616 KiB under `target/<host>` and 135,064 KiB under `target/debug`; the same ten without `--target` then compile 47 units and add 107,856 KiB. The 47 are the same crates `main`'s step compiles on the runner. **The seal at `9ef866436`, nightly run 37740449787** (conclusion success: `host`, `portability-linux`, `portability-macos`, `toolchain / build`, `tcg / suite`): ``` the cache entry, read by content: none restored: the run is cold the apps for linux: 10 app(s) pass `cargo build`; … the tree, sealed as the host cache's entry: 17010 files, 7493968284 B of the 8000000000 B an entry may hold; sealed: 2496 sources, built on Linux X64 ubuntu24 20261004.327.1, every target dated as built [ci] Seal: 80 step(s), all green ``` Units per step in its log, against the two columns above: | step | `9ef866436` | `88bcbf4d3` | `main` | |---|---|---|---| | `userland/*` | 225 | 225 | 289 | | the apps for linux | 42 | 282 | 47 | | the apps for macos | 264 | 248 | 248 | | the apps for windows | 240 | 239 | 239 | Every other step compiles what it did at `88bcbf4d3`. I expected 47 for the Linux apps: it is `main`'s 47 less `crc32fast`, `log`, `memchr`, `smallvec` and `toyos-keymap`, which an earlier step had compiled. I did not expect the macOS step's 16 more: all are host-side units (`syn`, `thiserror-impl`, `tokio-macros`, `futures-macro`, `autocfg` and the like), which the Linux step's `--target` build used to compile for the host and which the first `--target` step now compiles instead. The four steps together compile 771 units against 994 at `88bcbf4d3` and 823 on `main`. - Margin: 506,031,716 B under the limit, 6.3 %, on image 20261004.327.1. `main`'s 7,664,839,895 B was sealed on 20260927.320.1. The one pair of figures there is for the two images is `f260e0b98`, built with full debuginfo before #752 cut it to line tables: 8,540,783,725 B on 20260927.320.1 (run 37292450697) against 8,182,940,473 B on 20261004.327.1 (run 37601225884), 357,843,252 B or 4.2 % less on the newer. So this head's figure and `main`'s are not a pair, and this head is unmeasured on the older image. - Against the same branch before the fix and before #752: 9,348,536,345 B at `88bcbf4d3` on 20260927.320.1. **`ci.yml` run 37740454881 at `9ef866436`:** `host`, `toolchain / build` and `guest / suite` success. After this lands every `host` check runs cold until the first nightly on `main` seals and saves: the path list is the cache's version. **Toolchain keys.** The fold moves the sysroot key once: `userland/.cargo/config.toml` was one of its inputs and `.cargo/config.toml` replaces it. From now on a change to any guest triple's flags moves that key. The merges of #747 and #749 moved `toyos-abi` and `toyos`, so the sysroot key moved with `main`; the key at this head was not read here. ## No new gate, test or dependency No guest test is added or changed. No dependency is added. The proof is a one-off script because its subject is this one change against its base. ## Size `git diff --shortstat origin/main...HEAD` at `dd12c0b32`: 53 files, +5454 −7765. Without the locks: 48 files, +446 −704. `src/`, `tests/toyos.rs` and `tests/common/`: 12 files, +237 −360, of which tests are roughly +65 −115 by my reading of the hunks (an estimate, not a count). `issues/`: 16 files, +49 −115. ## What I am unsure of - **The seal on the older runner image.** GitHub serves two; this branch was sealed on the newer one, at `9ef866436`. The only pair of figures for the two is `f260e0b98` with full debuginfo (above): the older image sealed it 357,843,252 B larger. Carried unscaled onto this tree that leaves 148,188,464 B under the limit on the older image; scaled by the pair's ratio, about 178 MB. Both are arithmetic, not a run. - **`dd12c0b32` itself:** `ci.yml` run 37757675374 has `host` and `toolchain / build` success at it; its `guest / suite` is what the landing waits on. #757 (`b6bcb9691`) landed on `main` after this head was merged and measured: ten source files under `kernel/src`, `toyos-abi/src`, `toyos-userbound/src` and `tests/toyos-rust-tests`, no manifest and no lock; `git merge-tree --write-tree dd12c0b b6bcb96` exits 0. Nothing here was measured with it in. It differs from the sealed head by `main`'s #749, #750, #753 and #755 and the root lock's two edges; the seal's byte count at this head is unmeasured. - **Build wall clock.** One run under load; the fold was not slower. - **Clippy reaches further.** The bare-target shapes now also lint the kernel's and the loader's path dependencies for those targets. - **The licence gate reads a superset.** `--all-features` for the kernel now turns on every member's features. It judges more than ships. - **The runner's cargo.** The nightly's `host` at `88bcbf4d3` parsed the optional `include`, so the runner's cargo accepts it. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01RvnWQFcMuGqTHYhvSnTe8A
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
bootloader/Cargo.lockmoves its 8 registry crates that sat below the highest version another of the five main locks carries in the same semver range up to that version, and the loader's[profile.toyos]gainsstrip = "debuginfo", the one key in which it differed from the kernel's and userland's. This is the third and last alignment ofissues/the-tree-resolves-in-five-cargo-locks-not-one.md, the one-workspace track (stage 2 ofissues/the-tree-says-who-uses-each-thing.md); #724 and #732 were the first two. After it no registry pair of the five locks sits below its range's maximum, and the three[profile.toyos]tables have the same keys. No other manifest changes, no fork pin moves, and no other lock changes.What moved
align.sh(evidence comment 1) resets the lock toorigin/main's and runs onecargo update -p <name>@<old> --precise <new>per row, 8 rows, each exit 0, leaf first along the proc-macro chain. The lock diff is 18 lines in and 18 out: 8 versions and checksums, and the twosyn 2.0.48references.sums.sh). Each of the 8 is one the root lock already carries with the same checksum, and one the userland lock or the kernel lock carries too. Nothing enters or leaves the lock beyond the 8 old versions: no fetch new to the tree.libcpulls with it, which the track left unmeasured: nothing. Its lock entry has no dependencies, andreach.shfinds it on neither UEFI triple; on--target allits only edge is cpufeatures'.pairs-run.sh, running The root and kernel locks take the per-range maxima the five main locks already carry, the first stage of the one-workspace track #724'spairs.shunchanged on the committed locks). At0613f93f7it prints the 8 rows above; at the head it prints none.The profile line
strip = "debuginfo"is a no-op on this target as far as stripping goes: rustc's MSVC-flavour linker ignores-C strip(MsvcLinker::debuginfoin therust/fork), and the loader's link already writes no debug information (/DEBUG:NONEinbootloader/.cargo/config.toml). It lands now because the track's merge step must move no byte, and the merged workspace has one profile. It still moves the loader's bytes, because cargo hashes the profile into each unit's-C metadata:meta.sh(comment 4) shows that of the 26 (x86_64) and 24 (aarch64) units the loader links from, onlycore,alloc,compiler_builtinsand rustc'ssymbols.okeep their names, so every cargo unit is renamed, and lld lays the sections out in another order.Bytes before and after (negative control)
bytes.sh(comment 2) builds both arches at92f17c716and hashes 53 artifacts (both kernels, both loaders, the 49 userland binariesfindlists) four times: at the head (head1); withorigin/main'sbootloader/Cargo.toml, the aligned lock alone (nostrip); withorigin/main's manifest and lock, the whole change reverted (base, the control); and at the head again (head2). Every build exits 0, and every link map's rerun links an imagecmp-equal to the build's.head1andhead2are equal in all 53.staged-control.sh(comment 3) finds no copy of thebaseloader in a staged image, and that image differs from thebaseloader in 263,771 bytes at the place the head's loader sits, the same countanalyze.shgives for base → head.Which crates' code moved, and by how much
analyze.sh(comment 2) reads each loader's lld map (/lldmap) withfuncs.sh: every input section the image carries, by the crate that compiled it, and each.textsection's instructions, normalised so that a body at another address reads the same (hex numbers, immediates and branch labels writtenX).compare.shthen counts per crate the functions whose name and body are unchanged at the same address, unchanged at another address, and the ones whose name or body is in one image only.The lock (base → nostrip).
.text.rdatalog::__private_api::log(218 bytes on x86_64, 168 on aarch64) gives way to<log::__private_api::GlobalLogger as log::Log>::log(53, 76), andlog::set_loggergoes from 95 to 85 bytes (136 to 124). Its.textis 360 → 185 bytes on x86_64 and 368 → 264 on aarch64, its.rdata375 → 170 on both.rust_begin_unwind, the panic handler, which logs: 420 → 484 bytes on x86_64 and 300 → 352 on aarch64. Its.rdatais 719 → 600 on both.<toyos_elf::layout::Segment>::image, keeps its body; lld's identical code folding now also places<core::panic::location::Location>::fileon it, so it counts as one-sided by name only.The profile line (nostrip → head1). No function's name or body changes and no crate's size moves, in any section, on either arch. What moves is the layout: 363 of 530 functions sit at another address on x86_64 (219,421 bytes differ) and 133 of 514 on aarch64 (121,694 bytes differ), all of the latter in
bootloader,uefianduefi_services.Unlike #724 and #732, both changes here change the loader's bytes by design; the T14 is the evidence for how it behaves.
The track
Its counting paragraph says the locks agree; its exit records #732 and this alignment as the second and third; the constraint naming the loader's missing
stripand the sentence leaving the loader'slibcunmeasured are gone. "Four of them declare their own[profile.toyos]" becomes three: the root's went with toyos-ld in #726 (at the head,git grep '^\[profile.toyos\]'finds it, among the five resolutions' manifests, in the kernel's, userland's and the loader's only). The constraint paragraph measured at8b4f88446otherwise stands as measured there.Gates
The head is
f84e57ef8, the merge oforigin/main(b75ca2b4e: #734, #735) into2ad9f8956; the merge changes no loader file and no lock.gates2.shran the four in sequence there (orch/align3/gates2.log), andgates.shran them at2ad9f8956before the merge (orch/align3/gates.log), all green.f84e57ef8cargo run -- --build-only(x86_64)Build finished.(gate2-build-x86.log)cargo run -- --build-only --arch aarch64Build finished.(gate2-build-a64.log)cargo run -- --ci host[ci] Host: 75 step(s), all green(gate2-ci-host.log)cargo test(whole guest suite)test result: ok. 28 passed, 28 total (36.8s; workers: 197s building, 146s testing), thenchecks.rs34 passed and the empty doc-test target (gate2-guest.log)At
f84e57ef8both loaders hash asbytes.sh'shead2; the kernels differ, which #734 changes (gates2.log). At2ad9f8956all 53 artifacts hash ashead2(gates.log), so the track commit moves no byte.T14
The loader boots every T14 image, and every metal boot runs it twice: the pass that hands the kernel the machine, and, after the kernel's reset, the pass that reads the black-box page and appends its report to the same
loader.logthe driver reads back (tests/common/metal.rs,Boot::loader).stage.sh(comment 3) staged all 28 images of the metal profile atf84e57ef8withcargo test --test toyos-build -- --metal --metal-readback orch/align3/metal, which touches no machine (exit 2: staged, not judged), andstaged.shfinds the head's x86_64 loader, whole and byte for byte, in each of the 28 images at the same offset.Every row judges a boot of both passes. The rows that read the second pass's report as their verdict are
watchdog_fed(testcases-watchdog),blackbox_done_chainandmachine_reboot(jobcase),boot_deadline_ends_a_wedge(deadlinewedge),usb_reset_records_the_phase_it_cut(usbload),usb_stick_left(usbbreak),hard_lockup_ends_a_deaf_cpu(hardlockup) andblackbox_foreign_record(foreignrecord).orch/align3/metal/request.txtlists all 28.T14 RUN REQUESTED:
orch/align3/metal/request.txtin the orchestrator's job directory.What I am unsure of
funcs.shwrites every hex number and immediate asX, so a changed constant inside an otherwise equal body would read as unchanged. The section sizes, which it does not normalise, agree with it: in nostrip → head1 every crate's size in every section is equal.funcs.shattributes a function to the crate that compiled it, so a generic oflogoruefiinstantiated by the loader counts asbootloader's;bootloader's bodies are all unchanged under the lock, so no such instance changed.Net:
git diff --shortstat origin/main...f84e57ef8is 3 files, +27 −31:bootloader/Cargo.lock+18 −18,bootloader/Cargo.toml+1, the track +8 −13. No test is added or changed.🤖 Generated with Claude Code
https://claude.ai/code/session_01WcU2Dsw6mDYtwYfzVHPzM8