diff --git a/issues/a-crate-new-to-the-published-set-reds-every-publish-until-someone-puts-it-up-by-hand.md b/issues/a-crate-new-to-the-published-set-reds-every-publish-until-someone-puts-it-up-by-hand.md new file mode 100644 index 0000000000..4dfffc8cda --- /dev/null +++ b/issues/a-crate-new-to-the-published-set-reds-every-publish-until-someone-puts-it-up-by-hand.md @@ -0,0 +1,46 @@ +--- +status: open +kind: tooling +opened: 2026-10-20 +--- + +# A crate new to the published set reds every publish until someone puts it up by hand + +`publish.yml` publishes through crates.io trusted publishing, and a trusted +publishing token cannot create a crate. #905 (2c3f61a3e) put `toyos-untrusted` +and `toyos-transport` into `PUBLISHED` (`build/sdkversion.rs`), std's +dependencies through `library/Cargo.lock`, and neither exists on crates.io. So +main's 27 `publish` runs from 38558545002 (2c3f61a3e, 2026-10-14) to +39497368165 (9b11608ab, 2026-10-20) are red: 25 at the first new crate, and two +stopped earlier, 38719407453 at a git clone and 38727675385 at a moved tip. +The 25 answer + +> failed to publish toyos-untrusted ... (status 403 Forbidden): Trusted +> Publishing tokens do not support creating new crates. Publish the crate +> manually, first + +The crates after it in `PUBLISHED` have not gone up since: `toyos` and +`toyos-window` were last published on 2026-10-14 at 10:06Z. + +The nightly's `release` reads the same plan, finds `toyos-untrusted` owed at +main's tip, and refuses (`release::sdk_at_tip`): "crates.io holds no +toyos-untrusted of this tree, main's tip, so no sdk alias can name it". Runs +38701484274, 38868708235, 39013160165, 39108067326, 39221595037 and +39390441510 are red so, and the newest toolchain release and `sdk-` alias are +nightly 38533374419's, `toolchain-linux-x86_64-sdk-0.71.0` (2026-10-14 08:16Z). The refusal is right here and names the symptom, not the +failed publish (`issues/a-release-that-decides-before-its-tips-crates-are-up-reds-the-nightly.md`). + +The publish runs' and the releases' log lines, and crates.io's answers: +https://github.com/ToyOSOrg/evidence/tree/a36ad035c72df67b46d2ccee7a916fe5f521a5a3. + +Only an account can create a crate, and only then can it name `publish.yml` +the crate's trusted publisher. Nothing before a landing tells that a crate it +adds to `PUBLISHED` is not on crates.io. + +Owner: the owner's crates.io account for the first versions; `build/sdkversion.rs` +for the rule. + +**Exit**: `toyos-untrusted` and `toyos-transport` are on crates.io, each naming +`publish.yml` its trusted publisher; a `publish` run at main's tip and the next +nightly's `release` are green; and `PUBLISHED`'s doc comment says a crate joins +it only once crates.io holds it under that publisher. diff --git a/issues/a-driver-that-lends-its-device-a-handle-a-peer-sent-is-ended-when-it-is-no-region.md b/issues/a-driver-that-lends-its-device-a-handle-a-peer-sent-is-ended-when-it-is-no-region.md new file mode 100644 index 0000000000..050b7fa7c5 --- /dev/null +++ b/issues/a-driver-that-lends-its-device-a-handle-a-peer-sent-is-ended-when-it-is-no-region.md @@ -0,0 +1,37 @@ +--- +status: open +kind: defect +opened: 2026-10-20 +--- + +# A driver that lends its device a handle a peer sent is ended when it is no region + +`SYS_DEVICE_DMA_MAP` takes its region with `HandleTable::get` +(`sys_device_dma_map`, `kernel/src/syscall/device.rs`), so a handle of another +kind is `HandleError::WrongType`, which ends the caller, exit 139 +(`process::handle_fault`). `HandleTable::get_sent` answers `InvalidArgument` +for it instead, and is what `SYS_SPAWN` and `SYS_NAMESPACE_BUILD` take a +handle a peer sent with (`kernel/src/object/handle.rs`). + +The region a holder lends is a peer's by contract: `toyos_pci_claim::lend` +maps "`region`, which a peer lent", and reads `InvalidArgument` as +`Unlendable` (`lib/pci-claim/src/lib.rs`), a refusal the kernel never answers +for a handle of another kind. Since #953 the hda driver lends its controller +the ring soundserver sent with its acceptance, unchecked +(`offered` and `toyos_pci_claim::lend` in `system/hda/src/main.rs`): a +soundserver that sends a pipe end or a connection there ends hda rather than +being refused. diskserver is not reached, because `SharedMemory::lent` refuses +what `SYS_FSTAT` does not answer as a region before it maps one +(`system/diskserver/src/region.rs`). A region's kind is one `SYS_FSTAT` settles, +so this is not `issues/a-received-handle-has-no-knowable-type.md`'s case. + +The kernel owns the fix rather than each lender: what a holder lends is a +peer's by `lend`'s contract, and the kernel already answers a peer's handle of +the wrong kind `InvalidArgument` at `SYS_SPAWN` and `SYS_NAMESPACE_BUILD`; a +check before every lend would repeat that in each driver. + +Owner: the kernel's device calls (`kernel/src/syscall/device.rs`). + +**Exit**: `SYS_DEVICE_DMA_MAP` takes its region through `get_sent`, and +`HandleError::WrongType`'s comment names it beside `SYS_SPAWN` and +`SYS_NAMESPACE_BUILD`. diff --git a/issues/the-boot-volumes-server-holds-a-claim-that-writes.md b/issues/the-boot-volumes-server-holds-a-claim-that-writes.md index ff1c13cad6..794408cc8a 100644 --- a/issues/the-boot-volumes-server-holds-a-claim-that-writes.md +++ b/issues/the-boot-volumes-server-holds-a-claim-that-writes.md @@ -6,15 +6,22 @@ opened: 2026-10-10 # The boot volume's server holds a claim that writes +The boot volume is the ESP firmware loaded the loader from (`Role::Boot`, +`kernel/src/gpt.rs`): on the image the build writes it carries the loader and +`toyos/log.guid`, which the loader reads beside itself; the kernel and its +parameter are on the booted slot's volume (`Role::Slot`), which no file server +serves (`create_esp_volume` and `create_slot_volume`, `build/image.rs`). + On a disk the kernel drives — the boot stick, until usbd serves it — the -supervisor endows the boot volume's file server a partition claim on the -running slot's volume (`storage_endowment`, `system/supervisor/src/main.rs`). -A claim carries `Rights::WRITE` and no `DUP` (`initial_rights`, -`kernel/src/object/ops.rs`), so nothing can hand that server a duplicate -narrowed to reading: the volume the loader reads the kernel from stays -unwritten only by that server's promise to mount it read-only. On a disk the -block service serves, the same server's grant does not write, and diskserver -answers a write through it `ReadOnly` (`block_grants_reach_their_partitions`). +supervisor endows the boot role's file server a partition claim on the ESP +(`storage_endowment`, `system/supervisor/src/main.rs`). A claim carries +`Rights::WRITE` and no `DUP` (`initial_rights`, `kernel/src/object/ops.rs`), so +nothing can hand that server a duplicate narrowed to reading: the loader +firmware runs stays unwritten only by that server's promise to mount the ESP +read-only (`fat_on(disk, writable)`, `system/fileserver/src/main.rs`). On a +disk the block service serves, the same server's grant does not write, and +diskserver answers a write through it `ReadOnly` before the device sees it +(`system/diskserver/src/main.rs`'s module header). **Exit**: the boot volume's server on the boot stick holds a partition it cannot write — a read-only session once usbd serves the stick, or a claim the diff --git a/issues/the-host-caches-limit-reaches-the-10-gb-only-through-one-measured-ratio.md b/issues/the-host-caches-limit-reaches-the-10-gb-only-through-one-measured-ratio.md index 32f3e0331d..f7a2452f68 100644 --- a/issues/the-host-caches-limit-reaches-the-10-gb-only-through-one-measured-ratio.md +++ b/issues/the-host-caches-limit-reaches-the-10-gb-only-through-one-measured-ratio.md @@ -55,9 +55,25 @@ that run is red and saves nothing. Until an entry is sealed again, a pull request restores the last sealed one, or runs cold once the runner image has moved; either way its verdict is its steps'. +That is main's state since 2026-10-15, the second time, after 2026-10-05's +(`issues/a-red-nightly-on-main-is-reported-to-nobody.md`). Every scheduled +`host` since is red at its seal and only there, every earlier step green: run +38701484274 (979d4c539) counted 8,034,022,781 B in 17,193 files, and runs +38868708235, 39013160165, 39108067326, 39221595037 and 39390441510, all at +0e6716fc0, 8,033,230,395 to 8,033,351,794 B in 17,181 files. The last entry +saved is run 38533374419's (f0a987bc6, 2026-10-14): 7,293,414,884 B in 15,246 +files sealed, and the cache list says it stores 1,867,126,459 B, a ratio of +3.91. The fifteen landings f0a987bc6..979d4c539 added 740,607,897 B and 1,947 +files; which of them did is not measured. The 8 GB is this module's bound on +uncompressed bytes, not GitHub's: at that ratio the refused tree would store +about 2.06 GB. The repository's list held 10,562,836,502 B in 24 entries on +2026-10-20 regardless, the host entry and 23 toolchain layers. The seal lines of +these runs and that cache list: https://github.com/ToyOSOrg/evidence/tree/a36ad035c72df67b46d2ccee7a916fe5f521a5a3 (`nightly-host-seal`, `cache-list.json`). + Owner: the host cache (`build/cicache.rs`). -**Exit condition.** Two gates that red: +**Exit condition.** Nightly's `host` seals and saves main's tree again, and +three gates that red: - after nightly's `host` saves, a step reads that entry's stored bytes and every toolchain layer's from the repository's cache list, and fails when 2H + T passes 10 GB;