Code-side polish — close kernel/HAL/BSP non-blockers from comprehensive review (Track A/B/F/G/I)#15
Merged
Merged
Conversation
…A/B/F)
Closes the kernel/HAL non-blocker items from the 2026-05-06
comprehensive code review. Each is a localised tightening that the
reviewers identified as "still applies, low-priority" — none changes
runtime behaviour; build / test / miri all remain green.
## kernel/src/cap/table.rs (Track A non-blocker + obs)
- `CAP_TABLE_CAPACITY <= Index::MAX` migrated from `const _: () =
assert!(...)` to inline `const { assert!(...) }` form. Matches the
shape used in `Arena::new` ([obj/arena.rs:90](kernel/src/obj/arena.rs))
and applied during PR #10 R2 to other call sites; the const-block
form is the modern preferred shape per Phase A code review §Style.
- `cap_revoke`'s descendants-buffer size proof made explicit. The
invariant ("each live capability slot has exactly one parent and
appears in at most one parent's `first_child`/`next_sibling`
chain, so the BFS visits at most `CAP_TABLE_CAPACITY` distinct
indices") was implicit in the `cap_copy` / `cap_derive` /
`free_slot` invariants; Phase A code review asked for a one-liner
inside the function body. Comment added immediately above the
`descendants` allocation so a reader does not need to chase the
three sibling functions to reconstruct the bound.
## kernel/src/sched/mod.rs (Track A non-blocker)
- `SchedQueue::new` gains `const { assert!(N > 0, "SchedQueue
requires N > 0") }`. The wrap arithmetic in `enqueue` / `dequeue`
was already correct under N>0; Phase A code review noted N=0 was
*behaviourally* a zero-capacity queue but the type-level invariant
was unstated. Now a build-time hard error if any caller tries
`SchedQueue<0>`. `# Panics (compile-time)` doc-comment paragraph
added.
## hal/src/context_switch.rs (Track B non-blocker)
- `ContextSwitch` trait gains `: Send + Sync` super-trait bound.
Every other HAL trait (`Cpu`, `Console`, `Timer`, `IrqController`)
carries the bound; this was the only outlier. Comprehensive
review flagged it as "currently masked because all consumers also
bound `C: Cpu`, but a future `<C: ContextSwitch>`-only callsite
would silently lose multi-core safety". Aligning the bound now
closes the seam without observable behaviour change at HEAD.
## kernel/src/lib.rs (Track A observation)
- The kernel-stricter denylist's leading comment now explicitly says
"these layer onto `[workspace.lints]`; do NOT re-state workspace
denies here". Tracks the discipline Track A flagged as
"harmless-but-double-stated" in Phase A; the intersection at HEAD
is already correct (kernel adds `clippy::panic` / `unwrap_used` /
`expect_used` / `todo` / `arithmetic_side_effects` /
`float_arithmetic` over the workspace's `pedantic` + safety-block
set, no overlap), and the comment locks the discipline so a future
PR does not silently re-introduce duplication.
## kernel/src/obj/{task,endpoint,notification}.rs (Track F §F-3)
Three `#[cfg(test)] mod tests` blocks each had an `#[allow(...)]`
listing only `clippy::unwrap_used`. The other seven kernel-test
modules carry the trio `unwrap_used + expect_used + panic`. Aligned
all three to the trio. No new test logic; the existing tests in
these three modules don't currently use `expect` or `panic`, so the
addition is forward-protection (next test author can use the trio
without round-tripping a separate fix).
## Verification
`cargo fmt --check` clean; `cargo host-clippy` clean; `cargo
kernel-clippy` clean; `cargo host-test` 25 + 93 + 34 = **152/152**
(unchanged from B1 closure baseline); `cargo +nightly miri test`
**152/152** clean; `cargo kernel-build` clean.
Refs: comprehensive-review-2026-05-06, Track A, Track B, Track F
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes the BSP-side non-blocker items from the 2026-05-06 comprehensive code review. Each is a localised hardening that matches the discipline already applied to sibling sites. ## bsp-qemu-virt/src/cpu.rs (Track I §Non-blocking #3) - `Aarch64TaskContext` gains a compile-time size guard: `const _: () = assert!(core::mem::size_of::<Aarch64TaskContext>() == 168);`. PR #10 R2 added the same guard to `TrapFrame` (192 bytes) but did not back-fill the older `Aarch64TaskContext` site. The asm `naked_asm!` body in `context_switch_asm` reads byte offsets `0`/`80`/`88`/`96`/`104`; a Rust-side `repr(C)` drift would corrupt every cooperative switch. The guard turns that drift into a build-time hard error. Comment block above the assertion mirrors `TrapFrame`'s discipline. ## bsp-qemu-virt/src/exceptions.rs (Track G non-blockers) - `irq_entry`'s unused `_frame` parameter gains a one-paragraph doc-comment justifying its presence: future arcs (preemption, ESR/ELR-aware diagnostics, the scheduler-wake hook UNSAFE-2026-0014's Amendment named) will read or modify the frame. The leading underscore quiets the unused-parameter lint while the parameter remains live in the signature for the trampoline's calling- convention contract. - `irq_entry`'s spurious-IRQ branch's `compiler_fence(Ordering::SeqCst)` gains a defence-in-depth comment. The fence is structurally redundant on the early-return path (no following memory access reorders ahead of the return); kept as a guard against a future refactor that adds shared-state writes between spurious-detect and return. Documenting it as defence-in-depth makes the intent clear and pre-empts a future "drop the dead fence" PR that would remove the safeguard. ## bsp-qemu-virt/src/vectors.s (Track G non-blocker) - The IRQ trampoline gains a comment block pointing at the `TrapFrame` size assertion in `exceptions.rs:77`. The 192-byte stack carve-out and `stp` byte offsets are tightly coupled to the Rust-side `#[repr(C)]` struct definition; pairing the asm side with an explicit cross-reference to the Rust-side compile- time guard keeps both halves of the contract in the maintainer's mental model. ## bsp-qemu-virt/src/main.rs (Track G non-blocker — declined) - Track G's "append a defensive `loop { spin_loop }` after `start()`" recommendation is **declined** for `kernel_entry` specifically: `start` is `-> !`, so the type system already proves any code after the call is unreachable. Adding a parking loop fails build under `clippy::unreachable_code` and `clippy::too_many_lines`; the only "refactor regression" the loop would protect against is `start` losing its `-> !` qualifier — which itself becomes a compile error in every caller's return-type analysis. A 14-line comment block above the `start(...)` call records this rationale so a future reader does not re-litigate the suggestion. ## Verification `cargo fmt --check`, `cargo host-clippy`, `cargo kernel-clippy`, `cargo host-test` (152/152), `cargo +nightly miri test` (152/152), `cargo kernel-build` all clean. **QEMU smoke** reproduces the full demo trace through `tyrne: all tasks complete` (boot-to-end ~5.8 ms; `-d int,unimp,guest_errors` empty for the entire run): ```text tyrne: hello from kernel_main tyrne: timer ready (62500000 Hz, resolution 16 ns) tyrne: starting cooperative scheduler tyrne: task B — waiting for IPC tyrne: task A -- sending IPC tyrne: task B — received IPC (label=0xaaaa); replying tyrne: task A — received reply (label=0xbbbb); done tyrne: all tasks complete tyrne: boot-to-end elapsed = 5768000 ns ``` Refs: comprehensive-review-2026-05-06, Track G, Track I Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ⓘ You've reached your Qodo monthly free-tier limit. Reviews pause until next month — upgrade your plan to continue now, or link your paid account if you already have one. |
Reviewer's GuidePolishes kernel, HAL, and BSP code by tightening compile-time guarantees, documenting invariants and review decisions, and aligning lint/test policy without changing runtime behaviour or architecture. Class diagram for updated scheduling and context switch structuresclassDiagram
class ContextSwitch {
<<trait>>
+TaskContext
+unsafe fn context_switch(current: *mut TaskContext, next: *const TaskContext)
}
class SchedQueue_N_ {
<<generic N>>
-OptionTask buf[N]
-usize head
-usize tail
-usize len
+const fn new() SchedQueue_N_
+fn enqueue(task: TaskHandle) bool
+fn dequeue() OptionTask
}
class Aarch64TaskContext {
<<reprC>>
+u64 x19_x28[10]
+u64 fp
+u64 lr
+u64 sp
+u64 pc
+u64 pstate
+u64 d8_d15[8]
}
class TrapFrame {
<<reprC>>
+u64 gpr[31]
+u64 sp
+u64 elr
+u64 spsr
}
class KernelEntry {
+extern fn kernel_entry() !
}
class QemuVirtContextSwitch {
<<impl ContextSwitch>>
}
ContextSwitch <|.. QemuVirtContextSwitch
QemuVirtContextSwitch ..> Aarch64TaskContext : TaskContext
KernelEntry ..> SchedQueue_N_ : uses
KernelEntry ..> ContextSwitch : uses
TrapFrame ..> KernelEntry : irq_entry frame
TrapFrame ..> ContextSwitch : interrupt state
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
✅ Files skipped from review due to trivial changes (2)
🚧 Files skipped from review as they are similar to previous changes (4)
📝 WalkthroughWalkthroughThis PR strengthens compile-time safety and documentation clarity across the kernel. It adds build-time assertions linking Rust struct layouts to assembly hard-coded offsets, clarifies ABI contracts between Rust trampolines and assembly, adds ChangesBuild-time Safety and Documentation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- Several of the new comments embed very specific process metadata (dates, track names, review section numbers, relative paths, etc.); consider trimming these to the minimal technical rationale so the comments age well and don’t require updates when docs move or review structures change.
- Where comments refer to concrete locations (e.g.
exceptions.rs:77,../obj/arena.rs), it may be more robust to describe the relationship conceptually rather than via brittle file paths/line references that can easily drift with future refactors.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Several of the new comments embed very specific process metadata (dates, track names, review section numbers, relative paths, etc.); consider trimming these to the minimal technical rationale so the comments age well and don’t require updates when docs move or review structures change.
- Where comments refer to concrete locations (e.g. `exceptions.rs:77`, `../obj/arena.rs`), it may be more robust to describe the relationship conceptually rather than via brittle file paths/line references that can easily drift with future refactors.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces several documentation and safety improvements across the kernel and BSP. Key changes include adding compile-time size assertions for task contexts and trap frames to prevent layout drift, expanding lint rules for tests, and adding detailed architectural explanations and 'size proofs' in comments. Additionally, the ContextSwitch trait now requires Send + Sync and SchedQueue includes a compile-time check for non-zero capacity. Feedback focuses on improving the maintainability of comments by avoiding hardcoded line numbers and using robust rustdoc paths instead of relative file links for better documentation generation.
| // `Index::MAX`, so every `index.wrapping_add(1)` fits in `Index`. | ||
| const _: () = assert!(CAP_TABLE_CAPACITY <= Index::MAX as usize); | ||
| // Inline `const { assert!(...) }` matches the form used in | ||
| // `Arena::new` ([obj/arena.rs:90](../obj/arena.rs)); per Phase A |
There was a problem hiding this comment.
Referencing specific line numbers in comments (e.g., :90) is fragile as they will likely become stale as the referenced file evolves. It is better to refer to the item name or the file generally without a hardcoded line number to improve maintainability.
// Arena::new (see obj/arena.rs); per Phase A| // the Rust-side `TrapFrame` `#[repr(C)]` definition; a size or layout drift | ||
| // would corrupt every saved register on every IRQ. The compile-time guard | ||
| // `const _: () = assert!(core::mem::size_of::<TrapFrame>() == 192)` lives | ||
| // at `bsp-qemu-virt/src/exceptions.rs:77` and fails the build before the |
There was a problem hiding this comment.
Referencing a specific line number (:77) in exceptions.rs is prone to becoming outdated. Consider referring to the TrapFrame size assertion by name or context instead to ensure the comment remains accurate as the code changes.
// in bsp-qemu-virt/src/exceptions.rs and fails the build before the
| /// is allowed because the inline `const { assert!(N > 0, ...) }` here | ||
| /// turns the violation into a hard build error rather than runtime | ||
| /// short-circuit. Mirrors the `N == 0` discipline applied in | ||
| /// [`Arena::new`](../obj/arena.rs); per Phase A code review + comprehensive |
There was a problem hiding this comment.
The relative file link ../obj/arena.rs in a doc comment may not resolve correctly in generated documentation (e.g., via cargo doc). Using a rustdoc path like [crate::obj::arena::Arena::new] is more robust and provides better navigation in the generated HTML.
Suggested change
| /// [`Arena::new`](../obj/arena.rs); per Phase A code review + comprehensive | |
| /// [crate::obj::arena::Arena::new]; per Phase A code review + comprehensive |
…trim) Address inline + overall comments on PR #15. All four findings applied; comments now describe relationships conceptually rather than via brittle file-path / line-number references. ## Applied 1. **`kernel/src/cap/table.rs`** — `Arena::new`'s line ref `:90` dropped from the `const { assert!(...) }` migration comment. Reference now says "matches the form used in `Arena::new`" without a hardcoded line number. (gemini-code-assist-bot.) 2. **`bsp-qemu-virt/src/vectors.s`** — `exceptions.rs:77` line ref dropped from the cross-reference comment block. Comment now says the size-assertion "lives next to the `TrapFrame` definition in `bsp-qemu-virt/src/exceptions.rs`" — the symbolic anchor is stable as the file evolves. (gemini-code-assist-bot.) 3. **`kernel/src/sched/mod.rs`** — the `# Panics (compile-time)` doc on `SchedQueue::new` switched the `Arena::new` reference from a relative file link `[Arena::new](../obj/arena.rs)` to the rustdoc intra-doc link `[crate::obj::arena::Arena::new]`. The new form resolves both in `cargo doc` output and in IDE / GitHub-rendered markdown without depending on the relative-path hop. (gemini-code-assist-bot.) 4. **Process-metadata trim across the polish commits** — sourcery's overall feedback flagged the "per Phase A code review §Style + comprehensive review 2026-05-06 Track A non-blocker" tails embedded in several added comments. These are accurately tracked by the original commits' messages (`d86746a`, `03606a6`) and by git blame; the inline tails added review-process metadata that ages poorly when track names / review structures change. Tails trimmed from comments in: - `kernel/src/cap/table.rs` (×2 — both the const-block migration and the cap_revoke size-proof comment). - `kernel/src/sched/mod.rs` (the SchedQueue<0> doc-comment). - `bsp-qemu-virt/src/cpu.rs` (the Aarch64TaskContext size-guard comment). - `bsp-qemu-virt/src/exceptions.rs` (the spurious-IRQ defence-in- depth comment — kept the technical rationale, dropped the `Per comprehensive review ...` tail). - `bsp-qemu-virt/src/vectors.s` (the trampoline cross-reference block). - `bsp-qemu-virt/src/main.rs` (the kernel_entry "no defensive loop" rationale, simplified). The technical rationale (size proofs, defence-in-depth justifications, `-> !` type-level argument, `N == 0` discipline source) is fully preserved. ## Verification `cargo fmt --check` clean; `cargo host-clippy` clean; `cargo kernel-clippy` clean; `cargo host-test` 152/152; `cargo kernel-build` clean. No code logic changed; comments only. Refs: PR #15, comprehensive-review-2026-05-06 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
cemililik
added a commit
that referenced
this pull request
May 7, 2026
…2 prep activated Closes B1 — Drop to EL1 + exception infrastructure. The fresh closure trio replaces the 2026-04-28 trio's load-bearing role: that trio approved B1 implementation-complete based on host-test + miri + paper-review evidence; the maintainer-side QEMU smoke (still `Pending QEMU smoke verification` on UNSAFE-2026-0019/0020/0021 at the time) had not run. When the maintainer ran it on 2026-05-06, the smoke surfaced an idle-dispatch regression. T-014 fixed the regression; the comprehensive multi-agent code review (also 2026-05-06) generated α/β/γ doc-polish PRs; today's trio records what B1 actually is once smoke-verified end-to-end. ## Three new review artefacts - docs/analysis/reviews/business-reviews/2026-05-07-B1-closure.md — Period 2026-04-28 → 2026-05-07. What landed (T-014 + ADR-0026 + PRs #12 / #13 / #14 / #15); what changed in the plan (B1 reopen → T-014 fix → fresh closure; B2 prep reactivated; ADR-0026 repurposed); what we learned (smoke is the project's only end-to- end liveness oracle; ADR analysis must simulate, not just argue; comprehensive review's blind spot was "did you actually run the program?"; bot-driven review-rounds are productive when findings are factual-mechanical, less so when stylistic). Adjustments include "no closure-trio without recorded smoke", write-adr skill simulation-table check, comprehensive-review Track K — Live execution. - docs/analysis/reviews/security-reviews/2026-05-07-B1-closure.md — Eight axes, all OK. ADR-0026 / T-014 introduce no new attack surface, capability widening, memory-safety hazard, or threat- model shift. UNSAFE-2026-0014 third Amendment for register_idle; UNSAFE-2026-0019/0020 partial-verification + post-T-014 smoke Amendments; UNSAFE-2026-0021 no-verification Amendment. Eight inherited forward-flagged items unchanged at original severity. Verdict: Approve. - docs/analysis/reviews/performance-optimization-reviews/2026-05-07-B1-closure.md — Re-baseline. Net footprint-neutral vs 2026-04-28: .text 21,792 bytes (-116), .rodata 2,928 (+144), .bss 22,256 (+8). The +144 .rodata is panic-message clarity strings; the +8 .bss is idle: Option<TaskHandle>. Smoke 5.5–6.5 ms boot-to-end, zero events. 11 P-numbered proposals from Track D remain queued (P3 partially landed by γ; P1 / P10 / P4 highest-ROI near-term). No proposals to merge this cycle. Verdict: Merge. ## Status flips + index updates - T-014 In Review → Done. T-014 user-story file's review-history gains row 4 recording the maintainer's independent verification and the closure trio's landing. - docs/analysis/tasks/phase-b/README.md — T-014 row to Done. - docs/roadmap/phases/phase-b.md — sub-breakdown item 7 (T-014) flipped to Done; B1 status block rewritten ("B1 closed 2026-05-07") with citations to the three new review artefacts. - docs/roadmap/current.md — top callout rewritten to record B1 truly closed (2026-05-07); active phase remains B; active milestone advances to B2 (MMU activation); active task cleared (B2 prep / ADR-0027 drafting opens next per ADR-0025 §Rule 1); audit status footnote gains the 2026-05-07 update. - The three review-folder README index tables (business / security / performance) gain 2026-05-07-B1-closure rows. ## Verification recap - cargo fmt --check, cargo host-clippy -D warnings, cargo kernel-clippy -D warnings, cargo kernel-build — all clean. - cargo host-test 25 + 93 + 34 = 152/152. - cargo +nightly miri test 152/152 clean. - QEMU smoke at HEAD e9fa019 reproduces the full demo trace + the boot-to-end elapsed = ... line; -d int,unimp,guest_errors empty for the entire ~5.8 ms run. ## What stays open for δ + B2 prep - δ — write ADR-0023 placeholder file with Status: Deferred body (the README index gained the row in α; the file body is δ's job). - δ — endpoint rollback / ipc_cancel_recv ADR before B2 lands the first userspace destroy path (Track A non-blocker; SchedError::Deadlock rollback leaves endpoint in RecvWaiting). - B2 prep — ADR-0027 (kernel virtual memory layout) drafting + docs/architecture/memory-management.md design-first. The ADR's Dependency chain opens T-015 in the same commit per ADR-0025 §Rule 1. Refs: ADR-0026, ADR-0022, ADR-0025, T-014, B1 closure trio Audit: UNSAFE-2026-0014, UNSAFE-2026-0019, UNSAFE-2026-0020, UNSAFE-2026-0021 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced May 7, 2026
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.
Summary
This is the γ PR in the post-B1 fix-arc plan (α = PR #13 merged; β = PR #14 merged; γ = code-side small polish; then B1 closure trio; then B2 prep + δ).
Closes the localised tightening items from the 2026-05-06 comprehensive code review across Tracks A (Kernel), B (HAL), F (Tests), G (BSP), and I (Cross-track integration). All Phase A non-blockers that "still apply" + the new B0/B1-era non-blockers — kept as small surface, no architectural changes.
Commits
d86746achore(kernel,hal)— kernel + HAL polish (7 files, +40/-4):cap/table.rsCAP_TABLE_CAPACITY <= Index::MAXmigrated to inlineconst { assert!(...) }form (matchesArena::new's style);cap_revoke's descendants-buffer size proof made explicit as a multi-line comment above the BFS scratch allocation.sched/mod.rsSchedQueue::newgainsconst { assert!(N > 0, "SchedQueue requires N > 0") }so aSchedQueue<0>instantiation fails build instead of behaving as a zero-capacity queue at runtime;# Panics (compile-time)doc-comment paragraph added.hal/src/context_switch.rsContextSwitchtrait gains: Send + Syncsuper-trait bound (alignment with the other four HAL traits — closes the seam Track B flagged as "currently masked because all consumers also boundC: Cpu").kernel/src/lib.rsdenylist comment now explicitly says "these layer onto[workspace.lints]; do NOT re-state workspace denies here" — discipline-locking comment.kernel/src/obj/{task,endpoint,notification}.rstest-module#[allow(...)]blocks aligned to the triounwrap_used + expect_used + panic(matches the other seven test modules in the kernel; forward-protection for the next test author).03606a6chore(bsp)— BSP polish (4 files, +40/-1):bsp-qemu-virt/src/cpu.rsAarch64TaskContextgains a compile-time size guardconst _: () = assert!(size_of::<Aarch64TaskContext>() == 168)mirroringTrapFrame's PR Development #10 — T-012 (B1 IRQ infrastructure) + B0 closure retros #10 R2 guard.bsp-qemu-virt/src/exceptions.rsirq_entry's_frameparameter gains a one-paragraph justification comment (future arcs will read it; underscore quiets the lint until then); the spurious-branchcompiler_fencegains a defence-in-depth comment.bsp-qemu-virt/src/vectors.sIRQ trampoline gains a comment block pointing atexceptions.rs:77'sTrapFramesize assertion (asm/Rust frame-layout contract paired in the maintainer's mental model).bsp-qemu-virt/src/main.rsadds a 14-line comment block atkernel_entry's tail recording why Track G's "defensive parking loop" suggestion is declined for this site:startis-> !so the type system already proves no fall-through; adding a loop failsclippy::unreachable_code+clippy::too_many_lines; the suggested guard's only protection (againststartdropping-> !) is itself a structural refactor that becomes a build error in callers.Verification
cargo fmt --all -- --checkcargo host-clippycargo kernel-clippycargo host-testcargo +nightly miri testcargo kernel-buildtyrne: all tasks complete; boot-to-end ~5.8 ms;-d int,unimp,guest_errorsemptyOut of scope (deferred, with reasons)
The comprehensive review's verdict §"Non-blocking follow-ups" listed several items that need ADRs or are larger than the PR γ scope:
IpcError::WrongObjectKind/MissingRightsplit — needs ADR; perphase-b.mdADR-0030 (B5 syscall-ABI design venue) is the natural home.ipc_recv_and_yieldDeadlock endpoint rollback /ipc_cancel_recv— needs ADR; queued for δ (post-B1-closure, pre-B2).IrqQuard/IrqState(pub usize)BSP-only contract narrowing — needs Track B follow-up; can be a small ADR-0008 amendment.FakeCpu+FakeTaskContextlift totyrne-test-hal— needs an ADR-0020 follow-up + arena refactor; medium-size.ObjError::StillReachableno-producer decision (Track F §F-2) — needstesting.mdextension or variant deletion; small but needs maintainer call.proptest/bolerosetup forCapabilityTablederivation-tree invariants — B2-or-later.unsafe extern "C"block consistency — workspace toolchain bump; separate PR.#![deny(clippy::todo)]migration to[workspace.lints.clippy](Track J §J-OBS1) — minor lint hygiene.docs/decisions/0023-...mdplaceholder file (Deferred) — δ work.Test plan
cargo fmt --check,cargo host-clippy,cargo kernel-clippy,cargo host-test— all expected clean (152/152 host tests).cargo +nightly miri test— expected 152/152 clean../tools/run-qemu.sh— expected full demo trace throughtyrne: all tasks complete.const { assert!(...) }migration / addition fails build (with a clear message) under contrived violations (e.g. setCAP_TABLE_CAPACITY = u32::MAX as usize + 1or instantiateSchedQueue::<0>::new()in a test). (Recommended but not required; the assertions are mechanically obvious from the diff.)🤖 Generated with Claude Code
Summary by Sourcery
Tighten kernel, HAL, and BSP safety and invariants based on the 2026-05-06 comprehensive review non-blockers, without changing architecture or behavior.
Enhancements:
Summary by CodeRabbit
Refactor
Tests
Chores