Repository navigation
Conversation
Review r1 of #1282 at bd5851cCommit bd5851c on main 29c5f2d. I read the commit, the whole diff, all of ArchitectureThe change follows #1226's pattern and the approved mechanism:
Size: FindingsB1 sdk/toyos/src/endow.rs:193-196, 207-214, 601-614, 637-652, 771-800 — the two "two-copy" tests and their negative control exercise a test fixture, not the per-copy mechanism. The commit message claims more than they show.
S1 sdk/toyos/src/endow.rs:31, 35, 238, 461, 473, 531, 540 — S2 sdk/toyos/src/endow.rs:538-541 — the comment justifies S3 sdk/toyos/src/endow.rs:188, 286, 308 — the public docs of
Evidence and PR body (orchestrator)
SEND BACK |
…escriptor table std links its own copy of `toyos`, and a program that uses the SDK links another. Each copy kept its own record of what the process had done with its endowments: which names were taken, its launcher and the services it adopted. - A program's `toyos::endow` never saw what std adopted: `adopted_services_stay`'s adopter listed nothing after std had adopted `fs:/system`. - Nothing kept two copies from taking one label, which then had two owners. The launcher was such a label: each copy that launches took it for itself, so a program that launched through both std and its own copy would have held it twice. That state now lives once, in the copy that owns the descriptor table (std's in a Rust program, libc's in a C one), as #1226 made the stdio state single. That copy defines `toyos_endow_take`, `_holds`, `_launcher`, `_adopt` and `_adopted`, and every copy reaches the state through them. Each copy still reads the names itself, since they are the startup block's. - A name answers once in the process: a second take, from any copy, is refused. - The launcher is taken once, kept for the process's life and lent to every copy. - The adopted set is one set. What std adopts is what a program's `toyos::endow::services` and `connector` see, and a lookup through any copy ends the adoption. Off ToyOS a copy holds a state of its own, as the owner holds the process's. A host build only links it: a host binary such as the file server's links endowment code that never runs there, since reading the startup block reads a guest address. Host tests hold the state's rules: a name is taken once, the launcher is kept and refused to a take, and the adopted set is made once and ended by a lookup. That every ToyOS copy reaches the owner's one state rests on the arms' selection by target, by inspection, and on `adopted_services_stay`. Its adopter again checks that its own copy lists the `/system` std adopted. That check was red at main 302fb36 (run 43156966054), where std's adoption filled std's copy alone. The adopter lists only after adopting, since a listing ends the adoption. `issues/a-programs-own-toyos-never-sees-the-services-std-adopted.md` is closed. Its rule now heads `toyos::endow`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
bd5851c to
b9c8c16
Compare
Problem
std links its own copy of
toyos, and a program that uses the SDK links another. Each copy kept its own record of what the process had done with its endowments: which names were taken, its launcher and the services it adopted.toyos::endownever saw what std adopted.adopted_services_stay's adopter listed nothing after std had adoptedfs:/system. That was the red A sent handle of another kind is InvalidArgument whatever its rights, and adopted_services_stay checks only its own copy of toyos #1280 found and recorded inissues/a-programs-own-toyos-never-sees-the-services-std-adopted.md, which this PR closes.launcherfor itself (toyos::endow::launcher), so a program that launched through both std and its own copy would have held it twice. No test showed it, and nothing in the tree is known to have done it. It is recorded here, not as an issue, because this PR removes it.Resulting behaviour
The process's endowment state now lives once, in the copy that owns the descriptor table (std's in a Rust program, libc's in a C one), as #1226 made the stdio state single.
toyos_endow_take,toyos_endow_holds,toyos_endow_launcher,toyos_endow_adoptandtoyos_endow_adopted, and every copy, that one included, reaches the state through them. Only plain values cross: a label's bytes, a handle's number, and#[repr(C)]entries of a name and a connector.toyos::endow::servicesandconnectorsee, and a lookup through any copy ends the adoption.toyos::endow::adopt's and std'sadopt_services' docs say so.toyos_endow_*on the host ascrate::fddeclarestoyos_fd_*, and the file server's host build failed to link it (r15/below).The module header of
toyos::endownow states the rule, which is the closed record's durable line. The manual does not describe the SDK's copies, so it is unchanged.Checks and evidence
Evidence branch
pr-1282, at480a96b61. Each log ends with its exit code; local paths are masked. The head is b9c8c16, on main 29c5f2d. It differs from bd5851c, where the guest run below was dispatched, only insdk/toyos/src/endow.rs, by review r1's fixes, which change nothing a ToyOS copy does.Host tests hold the state's rules on a
Stateand a table directly (cargo test -p toyos,r1-fix/):a_name_is_the_handle_endowed_at_its_place_and_is_taken_once;a_service_stays_in_the_table;the_launcher_is_taken_once_and_answered_again: a take of it is refused, and every later ask answers it;the_adopted_set_is_made_once_and_ended_by_a_lookup.The cross-copy property rests on two things. One is the arms' selection by target, by inspection: on ToyOS outside tests,
heldis the extern arm, so a ToyOS copy cannot hold a local state, and a missing owner fails to link. The other isadopted_services_stayin the guest row below, whose check was red at main 302fb36 (run 43156966054) without this change. A first form's host "two-copy" tests and their control exercised a test fixture, not the copies; review r1 found that, and they are gone.Review r1's fixes, at b9c8c16 (
r1-fix/):cargo test -p toyos, clippy ontoyos(all targets andfd-table),--build-onlyand the file server's host suite all exit 0. They also put the state's predicate in one module, boundOnceonSend + SyncwithAdoptedSet'sSyncstated, keep the launcher asOption<RawHandle>, and drop the public docs' links to the crate-private state.Host checks (
r16/) at bd5851c, a clean tree, which review r1's fixes change only inendow.rs:--build-only;toyos-abi,toyos, the kernel library and the crates that link the SDK on the host (the libraries,shell-copies,toybox-copies, disks, diskserver, fileserver, netstack, nvme, pkg, session, soundserver and sshserver);toyos(all targets andfd-table), the libraries andtoyos-abi, and the kernel's shapes.All exit 0. The first form's run (
r15/) passed all but the file server's host tests, which failed to linktoyos_endow_*; that is what made a host build hold a local state.Guest rows, one run at bd5851c, the landing run: 43170266393, pending. The branch
endow-hold-bd5851cf0keeps that commit fetchable until it runs.testcases_members_exit_0: everytestcasesmember. Among them isadopted_services_stay, whose adopter checks again that its own copy lists the/systemstd adopted. That check was red at main 302fb36 (run 43156966054), where std's adoption filled std's copy alone; A sent handle of another kind is InvalidArgument whatever its rights, and adopted_services_stay checks only its own copy of toyos #1280 removed it, andendow.rsis unchanged from 302fb36 to this PR's base.a_launch_gives_each_unsent_stdio_slot_a_nullandsession_lifecycle: spawns and launches that endow handles, read back through every copy.They run on x86-64 QEMU, each one of
MACHINE_TESTS. No metal is staged or requested; the benches are down.Risks
no_stdcrates are libraries.🤖 Generated with Claude Code