feat(starry): add axbuild kmod support

[Godones]

• add StarryOS kmod build flow to axbuild
• build Rust kmods with the resolved Starry target, features, axconfig, and environment
• support Linux C kmods through module Makefiles when host arch matches target arch
• write .ko files next to the kernel ELF and support rootfs injection
• add kmod examples and module authoring documentation under os/StarryOS/lkm
• preserve kmod export anchors through a dedicated linker section
• update kmod dependencies to 0.3
• set LoongArch64 std target code model to small
• move default managed rootfs storage into tmp/axbuild/rootfs

Important notes:

• Rust kmods must share the kernel build context; otherwise Rust/core/alloc symbols and platform features can diverge from the kernel ELF.
• Release LTO must stay disabled for kernels expected to load Rust kmods.
• Linux C kmods are built only for matching host/Starry architectures because the sample Makefile uses the host Linux Kbuild tree.
• LoongArch64 std targets use code-model = small to match Linux's LoongArch Rust kernel build, which passes -Ccode-model=small through KBUILD_RUSTFLAGS. Keeping this in the target JSON makes the code model a property of the target instead of an axbuild-only special case.
• The rootfs cache no longer defaults to /tmp. That path is volatile on WSL, CI, tmpfs-backed hosts, and after reboot, which causes downloaded rootfs images to disappear and makes local StarryOS testing unnecessarily non-reproducible. Storing managed images under the workspace tmp directory keeps the cache tied to the checkout, persistent across reboot, easy to inspect, and easy to clean.
• TGOS_IMAGE_LOCAL_STORAGE still allows users to opt into a shared cache path.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR updates StarryOS kernel module (kmod) support by aligning the starry kmod build flow with the normal Starry build configuration, adding module discovery under os/StarryOS/lkm, and updating kernel/runtime pieces needed for module loading.

Changes:

• Switch starry kmod build to reuse resolved Starry build requests/Cargo config, add Rust+Linux-C module discovery, and support optional rootfs injection.
• Update kernel kmod memory allocation/unmapping logic and add a .kmod_export linker section.
• Add example modules/docs and bump kmod-related crate versions.

Reviewed changes

Copilot reviewed 16 out of 17 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
scripts/targets/std/pie/loongarch64-unknown-linux-musl.json	Adjust LoongArch64 code model setting for PIE target.
scripts/targets/std/loongarch64-unknown-linux-musl.json	Adjust LoongArch64 code model setting for non-PIE target.
scripts/axbuild/src/starry/mod.rs	Factor default build config generation into a shared helper used by build/qemu/kmod.
scripts/axbuild/src/starry/kmod.rs	Major rework: build kmods using Starry build context; add Linux C kmod support and rootfs injection; add tests.
scripts/axbuild/src/starry/build.rs	Add regression test for PIE target selection on plat-dyn builds.
scripts/axbuild/src/image/config.rs	Make default image storage location depend on axbuild_tmp_dir(base_dir).
os/StarryOS/starryos/linker.ld	Add .kmod_export section boundaries and KEEP directive.
os/StarryOS/lkm/linux-hello/linux-hello.c	Add example Linux C (Kbuild) kernel module.
os/StarryOS/lkm/linux-hello/Makefile	Add Kbuild Makefile for example Linux C module.
os/StarryOS/lkm/hello/src/lib.rs	Add example Rust kernel module crate.
os/StarryOS/lkm/hello/Cargo.toml	Add Cargo manifest for example Rust kernel module.
os/StarryOS/lkm/README.md	Document lkm layout, feature rules, build/injection process, and symbol checks.
os/StarryOS/kernel/src/kmod/mod.rs	Change kmod section allocation to vmem “vmalloc”-style mapping and unmap on drop.
os/StarryOS/kernel/Cargo.toml	Bump kmod-tools/kmod-loader dependency versions.
os/StarryOS/docs/kmod-axbuild-migration.md	Add migration plan/documentation for new axbuild-based kmod flow.
Cargo.toml	Add os/StarryOS/lkm/* workspace members, exclude Linux C module dir, add workspace dep for kmod-tools.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Godones]

@ZR233 由于该PR对axbuild和loongarch的构建配置做了修改，需要您亲自review一下，避免后续的修改破坏这些设置。

[mai-team-app]

审查总结

PR #1232 为 StarryOS 添加了 axbuild kmod 支持，整体设计方向正确：将 kmod 构建作为 Starry 构建模式而非独立 cargo 快捷方式，确保模块与内核共享相同的 target、features、axconfig 和编译上下文。代码结构清晰，文档详尽。

审查中发现的阻塞问题如下，需要修复后重新审查。

变更概述

• 重写 cargo xtask starry kmod build，复用 Starry 构建请求和 Cargo 配置
• 新增 os/StarryOS/lkm/ 示例模块（Rust hello 模块 + Linux C linux-hello 模块）
• 重构内核 kmod 内存分配：从全局页面分配器迁移到 vmalloc 风格的虚拟地址分配
• 添加 .kmod_export 链接器段
• 将 kmod 相关 crate 版本从 0.2/0.2.1 升级到 0.3
• 将默认根文件系统存储从 /tmp 移至 tmp/axbuild/rootfs
• 设置 LoongArch64 std target 的 code-model 为 small
• 将 tempfile 从 dev-dependencies 提升为正式依赖

本地验证

• cargo fmt --check：通过 ✅
• cargo test --manifest-path scripts/axbuild/Cargo.toml --all-features：637 passed, 1 failed（失败项 checked_in_build_configs_do_not_declare_default_dynamic_builds 为预存问题，与本次 PR 变更无关）

CI 状态

• Detect changed paths：success ✅
• Run sync-lint / run_container：success ✅
• Check formatting / run_host：success ✅
• 多组 run_host/run_container 互为排他矩阵，一侧 skipped 为预期行为
• 有多个 job 被取消（cancelled），这属于 CI 基础设施层面的问题，非本次 PR 引入
• Test arceos riscv64 qemu / run_host：failure，但该失败源于 ArceOS 构建配置中 plat_dyn = true 的预存问题，与本次 PR 无关

重复/重叠分析

搜索 repo:rcore-os/tgoskits type:pr state:open kmod 仅返回本 PR #1232 和一个无关的 macOS self-build PR #984，不存在重复或重叠。

关于 Copilot 审查意见

Copilot bot 在上一个提交 (fbd2dc3) 上留下的 5 条评论中：

• TargetKind::Lib 匹配问题：当前 cargo_metadata 版本中 TargetKind 确为枚举类型，该评论不适用
• TempOverlayDir 手动临时目录：已在第二个提交 (2fc4fea) 中使用 tempfile::Builder 替代，已修复 ✅
• 路径重复：文档中的双路径问题尚未修复（见下文）
• kmod 分配 panic 和地址范围约束：尚未修复（见下文）

阻塞问题

1. 内核 panic 风险 (os/StarryOS/kernel/src/kmod/mod.rs): alloc_kmod_frames 函数中 find_free_area 调用使用了 .expect()，在找不到空闲虚拟地址区域时会导致内核 panic。内核代码中应避免 panic，改用适当的错误处理（返回 AxError::NoMemory）并让调用方决定如何处理。

2. 地址范围约束未实现 (同上): 注释说明需要限制在 kernel_end 的 2 GiB 范围内以支持 32 位相对重定位，但实际搜索范围 VirtAddrRange::new(guard.base(), guard.end()) 是整个内核地址空间，未实施该约束。应修正为约 VirtAddrRange::new(kmod_alloc_start, kmod_alloc_start + 2 * 1024 * 1024 * 1024)。

3. 文档路径错误 (os/StarryOS/docs/kmod-axbuild-migration.md): 快速入门示例中的 --rootfs 路径包含重复的镜像文件名 rootfs-riscv64-alpine.img/rootfs-riscv64-alpine.img，应为单一镜像路径。

Powered by deepseek-v4-pro

[mai-team-app]

审查总结（续前次审查）

这是对 PR #1232 的跟进审查。前次审查（mai-team-app #4478070947）已提交 CHANGES_REQUESTED，指出了 3 个阻塞问题和 1 个已修复问题。

前次审查问题状态

#	问题	状态
1	alloc_kmod_frames 中使用 .expect() 可能导致内核 panic	❌ 未修复
2	虚拟地址范围约束未实现（应限制在 kernel_end 的 2 GiB 内）	❌ 未修复
3	文档中 --rootfs 路径重复（双写镜像文件名）	❌ 未修复
4	TempOverlayDir 手动临时目录 → 使用 tempfile::Builder	✅ 已修复

本地验证

• cargo fmt --check：通过 ✅
• cargo test --manifest-path scripts/axbuild/Cargo.toml --all-features：637 passed, 1 failed ✅（唯一失败的 checked_in_build_configs_do_not_declare_default_dynamic_builds 为预存问题，与本次 PR 无关）

CI 状态

• Detect changed paths：success ✅
• Run sync-lint / run_container：success ✅（据前次审查）
• Check formatting：已取消，但本地 fmt 检查通过 ✅
• 多个排他性矩阵 job（run_host/run_container）已 skipped，为预期行为
• 多个 job 被取消（cancelled），属于 CI 基础设施层面问题，非本次 PR 引入

关于 Copilot 评论

• TargetKind::Lib 类型问题：当前使用的 cargo_metadata 0.23.1 中 TargetKind 为枚举类型，matches!(kind, TargetKind::Lib) 是正确的用法，代码编译通过，测试也通过。此评论不适用。
• 临时目录问题：已在当前 head 中使用 tempfile::Builder 替代，已修复。

阻塞问题（与上次相同）

上述 3 个未修复问题仍是阻塞性的，详见下方行内评论。请修复后重新提交审查。

Powered by deepseek-v4-pro

[ZR233]

审查当前 head 2fc4fea6b0a373ec6f89a9b7a81781fa0b162a1f 后，整体方向是合理的：starry kmod build 复用 Starry build request/Cargo config、Rust kmod 示例能生成 .ko，.kmod_export section 也接到了 linker script 里；但还有一个会影响模块实际加载可靠性的阻塞点，需要先修掉。

阻塞问题：

• alloc_kmod_frames() 的地址范围还没有真正限制在 kernel end 后 2 GiB 内。当前 find_free_area() 的 limit 是整个 kernel aspace，注释里的 2 GiB 约束没有生效；一旦附近没有空洞，模块可能被放到超出 PC-relative relocation 可达范围的位置，insmod 会在 relocation 阶段失败。详见行内评论。
• 文档第 255 行有 trailing whitespace，git diff --check origin/dev...HEAD 当前会失败，也已留行内评论。

本地验证结果：

• cargo fmt --check：通过。
• cargo xtask clippy --package axbuild：通过。
• cargo xtask clippy --package hello：8/8 checks 通过。
• cargo test --manifest-path scripts/axbuild/Cargo.toml --all-features：637 passed, 1 failed；失败项是既有的 checked_in_build_configs_do_not_declare_default_dynamic_builds，不是本 PR 改动面。
• cargo xtask starry build --arch x86_64：通过。
• cargo xtask starry kmod build --arch x86_64 -m os/StarryOS/lkm/hello：通过，生成 target/x86_64-unknown-linux-musl/release/hello.ko。
• hello.ko 为 ELF relocatable，且其 undefined symbols 在同一次构建出的 starryos 符号表中都能找到。
• --rootfs tmp/axbuild/rootfs/<image>/<image> 这个路径形态我重新核对过，和当前 image storage/extract 逻辑一致，因此不再把旧评论里的“重复镜像名”作为阻塞。

CI 归因：当前 run https://github.com/rcore-os/tgoskits/actions/runs/27353873878 的唯一 failure 是 Test arceos riscv64 qemu / run_host，日志里是 test-suit/arceos/rust/src/task/sleep.rs 的 now.elapsed() >= Duration::from_millis(50) 断言失败；这个 PR 没有改 ArceOS task/timer/sleep/IPI 路径，我已把它作为既有并发/调度类样本补到 #131：#131 (comment) 。后续多个 job 是 cancelled，暂不作为本 PR 的独立回归判断。

开放 PR 重叠面：#984 会碰到 Starry kernel/linker 附近代码，#1231 会碰到 axbuild/rootfs 流程，但没有看到与本 PR 的 kmod build 支持构成重复实现；主要是后续合并时需要留意冲突。

[ZR233]

这里仍然没有把模块 section 的可用 VA 限制在 kernel_end 后 2 GiB 内。find_free_area() 会在传入的 limit 里找空洞，现在给的是整个 kernel aspace，所以一旦 kernel_end 附近没有合适空洞，就可能把模块放到更远的位置；而 x86_64/RISC-V/AArch64 的 PC-relative/call/page reloc 都有距离限制，后续 relocation 可能直接 overflow，导致 insmod 在运行时失败。建议把 limit 改成从 kmod_alloc_start 开始、上界为 min(kmod_alloc_start + 2GiB, guard.end()) 的范围，并对 checked_add/无可用空间场景显式处理，而不是退回到全地址空间。

[mai-team-app]

审查总结

这是对 PR #1232（当前 head 27f8d66）的跟进审查。该 PR 为 StarryOS 添加了 axbuild kmod 支持，整体设计方向正确：将 kmod 构建作为 Starry 构建模式复用解析后的 target、features、axconfig 和编译上下文。代码结构清晰，文档详尽，tempfile 使用和 TargetKind::Lib 等前次审查中提到的问题已修复。

变更概述

• 重写 cargo xtask starry kmod build，复用 Starry 构建请求和 Cargo 配置
• 新增 os/StarryOS/lkm/ 示例模块（Rust hello + Linux C linux-hello）
• 重构内核 kmod 内存分配：从全局页面分配器迁移到 vmalloc 风格虚拟地址分配
• 添加 .kmod_export 链接器段
• 将 kmod 相关 crate 版本从 0.2 升级到 0.3
• 将默认 rootfs 存储从 /tmp 移至 tmp/axbuild/rootfs
• 设置 LoongArch64 std target 的 code-model 为 small
• 将 tempfile 从 dev-dependencies 提升为正式依赖

本地验证

• cargo fmt --check：通过 ✅
• git diff --check origin/dev...HEAD：通过 ✅
• cargo xtask clippy --package hello：8/8 checks 通过 ✅
• cargo test --manifest-path scripts/axbuild/Cargo.toml --all-features：637 passed, 1 failed；唯一失败项 checked_in_build_configs_do_not_declare_default_dynamic_builds 为预存 ArceOS 配置问题，与本次 PR 无关 ✅

CI 状态

当前 head 27f8d66 的 CI run 27389942931：

• Detect changed paths：success ✅
• Run sync-lint / run_container：success ✅
• Cancel stale CI runs：success ✅
• Check formatting / run_host：queued（本地 fmt 已通过）
• Check formatting / run_container：skipped（排他性矩阵，预期行为）
• Run sync-lint / run_host：skipped（排他性矩阵，预期行为）
• Publish * jobs：skipped（分支限制，预期行为）

早前 run 中 Test arceos riscv64 qemu / run_host 的失败为预存 ArceOS task/timer 并发问题，已由 ZR233 补入 issue #131 跟踪，与本次 PR 无关。

前次审查问题状态

#	问题	状态
1	alloc_kmod_frames 中使用 .expect() 导致内核 panic 风险	❌ 未修复（见下方行内评论）
2	虚拟地址范围未限制在 kernel_end 的 2 GiB 内	❌ 未修复（见下方行内评论）
3	文档中 --rootfs 路径重复	✅ 经 ZR233 核对，当前路径形态与 image storage/extract 逻辑一致，无需修改
4	TempOverlayDir 手动临时目录已替换为 tempfile::Builder	✅ 已在 head 27f8d66 中修复
5	文档 trailing whitespace	✅ git diff --check 通过

关于 Copilot 评论

• TargetKind::Lib 类型问题：当前 cargo_metadata 0.23.1 中 TargetKind 为枚举类型，matches!(kind, TargetKind::Lib) 用法正确，代码编译通过且测试通过，此评论不适用。
• TempOverlayDir 手动临时目录：已在当前 head 中使用 tempfile::Builder 替代，已修复。

重复/重叠分析

搜索 repo:rcore-os/tgoskits type:pr state:open kmod OR axbuild OR lkm，相关 open PR：

• PR #1231 (pengzechen)：macOS QEMU/rootfs 鲁棒性改进，虽涉及 axbuild 但属于不同域（QEMU 环境适配 vs kmod 构建），不存在重复或冲突
• PR #1236 (shilei-massclouds)：sync-lint 扩展，无关

本 PR 的 kmod build 支持没有与其他 open PR 构成重复实现。PR #1231 可能需要在合并时留意 axbuild 冲突。

阻塞问题

以下 2 个问题自前次审查以来仍未修复，属于阻塞性问题。详见下方行内评论。

1. 内核 panic 风险 (os/StarryOS/kernel/src/kmod/mod.rs 第 122 行和第 143 行)：alloc_kmod_frames 和 vmalloc 中使用 .expect() 会在找不到空闲虚拟地址区域或内存不足时导致内核 panic。内核代码中应避免 panic，改用错误处理返回 AxError::NoMemory 并让调用方决定如何处理。

2. 虚拟地址范围约束未实现（同文件第 120 行）：注释说明需要将模块限制在 kernel_end 后约 2 GiB 范围内以支持 32 位相对重定位，但当前 VirtAddrRange::new(guard.base(), guard.end()) 搜索整个内核地址空间，未实施该约束。应修改为类似 VirtAddrRange::new(kmod_alloc_start, kmod_alloc_start + 2 * 1024 * 1024 * 1024) 的范围，并在超出范围时返回错误而非 panic。

请修复后重新提交审查。

Powered by deepseek-v4-pro

[ZR233]

跟进审查当前 head 27f8d6695748f7e7b616fc39ef057428caf10bca：文档 trailing whitespace 已修复，git diff --check origin/dev...HEAD 通过；cargo fmt --check 和 cargo xtask clippy --package axbuild 也通过。

不过前次审查中的核心阻塞点仍然存在：alloc_kmod_frames() 仍用 VirtAddrRange::new(guard.base(), guard.end()) 搜索整个 kernel aspace，没有把 kmod section 分配限制在 kernel end 后 2 GiB 范围内。作者回复里提到“目前不用施加这个限制”，但这个限制不是注释风格问题，而是 loader 能否处理 PC-relative/call/page relocation 的运行时正确性条件。即使当前 KernelModuleHelper::vmalloc trait 还没有合适的错误返回通道，也不能让成功分配落到 relocation 不可达的地址。

因此本轮仍然请求修改：请把 find_free_area() 的 limit 改成从 kmod_alloc_start 开始、上界为 min(kmod_alloc_start + 2GiB, guard.end()) 的范围，并显式处理 checked_add/无可用范围场景。旧的 2GiB 地址范围线程我已重新打开，并在当前 diff 第 120 行补了新的行内评论。

CI 状态：当前 head 的 CI run 27389942931 中 Detect changed paths、Run sync-lint / run_container、Cancel stale CI runs 已通过；Check formatting / run_host 仍处于 queued/pending。本地格式与 diff 检查已通过，但 CI 尚未完整结束，不能视为全绿。重复/重叠分析沿用上一轮结论：与 #1231/#984 有 axbuild/Starry kernel-linker 层面的交集或冲突风险，但没有看到重复实现。

[ZR233]

复查当前 head 27f8d6695748f7e7b616fc39ef057428caf10bca，本轮仍需要 request changes。

合并要求逐项检查：

• PR 主要把 Starry kmod 构建从旧的裸 cargo build --manifest-path 重构为复用正常 Starry build context：先解析 --arch/--target/--config/--smp/--debug，再加载 build::load_cargo_config，对模块仅切换 package/bin/output/post-build 处理。这条方向是合理的，因为 Rust kmod 必须和内核共享 target JSON、features、axconfig、AX_CONFIG_PATH/AX_PLATFORM 等构建上下文。
• LoongArch64 std target JSON 的 code-model = small 修改有实际作用：axbuild 生成的 std Cargo config 已经刻意不再额外注入 -C code-model，所以 code model 会由 scripts/targets/std/{,pie}/loongarch64-unknown-linux-musl.json 直接控制 rustc/LLVM codegen。对照 Linux LoongArch Rust kernel 的架构 Makefile，其 Rust flags 确实使用 -Ccode-model=small，因此把该策略放入 target JSON 比在 axbuild 里写特殊分支更一致。不过这会影响所有走这两个 LoongArch std target JSON 的构建面，不只是 kmod。
• 关于旧 build-mod shell：在当前 base 和本 PR head 中没有发现可删除的 kmod/lkm/module build .sh。仓库内仍存在并应保留的是 os/StarryOS/scripts/kmod-linker.ld 和 scripts/axbuild/scripts/starry-kallsyms.sh；前者仍被 kmod partial link 使用，后者仍是 Starry 内核 kallsyms 后处理，不是本次重构后可移除的旧 kmod shell。文档中提到的 upstream modules/kmod.mk / make/build.mk 只是迁移背景。
• 未发现 [patch.crates-io]；git diff --check origin/dev...HEAD 通过；git merge-tree origin/dev HEAD 无冲突输出。
• 本地验证：cargo fmt --check 通过；cargo test -p axbuild starry::kmod -- --nocapture 通过（7/7）；cargo xtask clippy --package axbuild 通过。
• Rust kmod 实际流程验证通过：cargo xtask starry kmod build --arch x86_64 -m os/StarryOS/lkm/hello 成功生成 target/x86_64-unknown-linux-musl/release/hello.ko；file/rust-readobj --file-headers 确认它是 x86_64 ET_REL relocatable ELF，rust-nm -u 可见预期的 undefined kernel/Rust symbols。
• Linux C kmod 实际流程验证失败，已在 os/StarryOS/lkm/linux-hello/Makefile 留 inline 阻塞评论。
• 仍保留现有未解决 thread：alloc_kmod_frames() 当前仍用整个 kernel aspace 作为 find_free_area() 的 limit，没有把模块 section 限制在内核附近的可达范围。kmod-loader 对 x86_64 PC32/PLT32、AArch64 branch/page、RISC-V PC-relative、LoongArch branch/PC-relative relocation 都存在范围/overflow 约束，这个问题不能仅以“目前不用考虑”关闭。
• CI 当前 head 多数相关 job 已通过（format、sync-lint、std、LoongArch/Starry/ArceOS/Axvisor 多项）；查询时 Run clippy / run_host 与 Test starry x86_64 qemu / run_container 仍为 pending，且本地已复现一个 PR 相关的 Linux C kmod 失败。
• 重复/重叠检查：base 只有旧的 Rust kmod builder；open PR 中 #1231 也触及 axbuild/rootfs 但主题是 macOS qemu/rootfs robustness，#1214/#1207 触及 LoongArch 平台/axvisor，均不是同一 kmod/target JSON 实现的重复 PR。

请先修复 Linux C kmod host-match 构建失败，并处理或明确消除模块 VA 可达范围问题后再复审。

[Godones]

@ZR233 若无其它问题，请帮忙合并该PR

[mai-team-app]

审查总结

PR #1232 为 StarryOS 添加 axbuild kmod 支持，将 starry kmod build 重构为复用正常 Starry 构建上下文（target、features、axconfig、Cargo env），整体设计方向正确。代码结构清晰，文档详尽，测试覆盖充分。

变更概述

• 重写 cargo xtask starry kmod build，复用 Starry build request / Cargo config
• 新增 os/StarryOS/lkm/ 示例模块（Rust hello + Linux C linux-hello）
• 重构内核 kmod 内存分配：从全局页面分配器迁移到 vmalloc 风格虚拟地址分配
• 添加 .kmod_export 链接器段 + kshim.rs 兼容性符号（x86 return thunk）
• 将 kmod 相关 crate 版本从 0.2 升级到 0.3
• 将默认 rootfs 存储从 /tmp 移至 tmp/axbuild/rootfs
• 设置 LoongArch64 std target 的 code-model = small
• 将 tempfile 从 dev-dependencies 提升为正式依赖

本地验证

• cargo fmt --check：通过 ✅
• git diff --check origin/dev...HEAD：通过 ✅
• cargo test --manifest-path scripts/axbuild/Cargo.toml --all-features：637 passed, 1 failed ✅
  • 唯一失败项 checked_in_build_configs_do_not_declare_default_dynamic_builds 为预存问题，与本次 PR 无关

CI 状态

当前 head 796014a9d 的 CI 关键检查已通过（Detect changed paths、Run sync-lint、Check formatting 均 success）。多个排他性矩阵 job 为 skipped，属预期行为。此前 Test arceos riscv64 qemu / run_host 的失败为预存的 ArceOS task/timer 并发问题（sleep 断言失败），与本 PR 无关，已由 ZR233 补入 issue #131 跟踪。因此 CI 通过，无需本地重复测试。

前次审查问题状态

#	问题	状态
1	alloc_kmod_frames 中 .expect() 导致内核 panic	✅ 已修复（改为 .ok_or(AxError::NoMemory)?）
2	虚拟地址范围未限制在 kernel_end 的 2 GiB 内	❌ 未修复（见下方行内评论）
3	文档 --rootfs 路径形态	✅ ZR233 核实与 image storage/extract 逻辑一致
4	TempOverlayDir 手动临时目录	✅ 已改用 tempfile::Builder
5	文档 trailing whitespace	✅ git diff --check 通过

关于 Copilot 审查意见

• TargetKind::Lib 类型问题：当前 cargo_metadata 0.23.1 中 TargetKind 为枚举类型，matches!(kind, TargetKind::Lib) 用法正确。此评论不适用。
• 临时目录问题：已在当前 head 中修复。

关于 vmalloc 中的 .expect()

KmodHelper::vmalloc 仍使用 .expect("kmod vmalloc: out of memory")。alloc_kmod_frames 现在正确返回 AxResult<VirtAddr>，但 KernelModuleHelper::vmalloc 的 trait 签名为 fn vmalloc(size: usize) -> Box<dyn SectionMemOps>，不支持返回 Result。因此 .expect() 是在当前 trait 约束下的唯一选择。建议后续向 kmod-loader 上游提 trait 签名修改。此项为建议性意见，不阻塞合并。

重复/重叠分析

搜索 repo:rcore-os/tgoskits type:pr state:open kmod OR axbuild OR lkm：

• PR #1231：macOS QEMU/rootfs 鲁棒性改进，涉及 axbuild 但属于不同域，不存在重复
• PR #1236：sync-lint 扩展，无关
• 无重复实现

阻塞问题

以下问题自 ZR233 首次审查以来已跨越多轮仍未修复，属于阻塞性问题：

内核 kmod 虚拟地址范围约束未实现 (os/StarryOS/kernel/src/kmod/mod.rs)：alloc_kmod_frames 中 find_free_area 的搜索范围仍为 VirtAddrRange::new(guard.base(), guard.end())，即整个内核地址空间。注释说明应将模块分配限制在 kernel_end 后约 2 GiB 范围内以支持 32 位 PC-relative 重定位（x86_64 RIP-relative ±2GiB、AArch64 branch/page、RISC-V PC-relative、LoongArch branch/PC-relative），但约束未生效。当模块被分配到超出 relocation 可达范围的地址时，insmod 会在 relocation 阶段失败。

请将搜索范围修改为 VirtAddrRange::new(kmod_alloc_start, min(kmod_alloc_start + 2GiB, guard.end())) 并显式处理无可用范围的情况。

Powered by mimo-v2.5-pro

[ZR233]

请rebase 最新 dev ，看 ci 能过么，已经重跑多次不过， dev 修复了部分随机失败问题

[mai-team-app]

审查总结

PR #1232 为 StarryOS 添加 axbuild kmod 支持，将 starry kmod build 重构为复用正常 Starry 构建上下文（target、features、axconfig、Cargo env），整体设计方向正确。代码结构清晰，文档详尽，测试覆盖较充分。新增的 kshim.rs 解决了 Linux C kmod 的 __x86_return_thunk 兼容性符号问题。

变更概述

• 重写 cargo xtask starry kmod build，复用 Starry build request / Cargo config
• 新增 os/StarryOS/lkm/ 示例模块（Rust hello + Linux C linux-hello）
• 重构内核 kmod 内存分配：从全局页面分配器迁移到 vmalloc 风格虚拟地址分配
• 添加 .kmod_export 链接器段 + kshim.rs 兼容性符号（x86 return thunk）
• 将 kmod 相关 crate 版本从 0.2 升级到 0.3
• 将默认 rootfs 存储从 /tmp 移至 tmp/axbuild/rootfs
• 设置 LoongArch64 std target 的 code-model = small

本地验证

• cargo fmt --check：通过 ✅
• git diff --check origin/dev...HEAD：通过 ✅
• 无 [patch.crates-io] 依赖 ✅

CI 状态

当前 head 349a40f 的 CI run 27424344222 中所有 job 均为 skipped 结论。这可能是 CI 基础设施问题或路径过滤导致。ZR233 已要求作者 rebase 最新 dev 分支以解决此前多次 CI 随机失败问题。当前 CI 状态不完整，不能作为通过依据。

前次审查问题状态

#	问题	状态
1	alloc_kmod_frames 中 .expect() 导致内核 panic 风险	✅ 已修复为 .ok_or(AxError::NoMemory)?
2	虚拟地址范围未限制在 kernel_end 的 2 GiB 内	❌ 未修复（见下方行内评论）
3	TempOverlayDir 使用 tempfile	✅ 已修复
4	文档 trailing whitespace	✅ 已修复
5	Linux C kmod __x86_return_thunk 缺失	✅ 已通过 kshim.rs 修复

关于 Copilot 评论

• TargetKind::Lib 类型问题：当前 cargo_metadata 版本中 TargetKind 确为枚举类型，matches!(kind, TargetKind::Lib) 是正确用法，代码编译且测试通过。此评论不适用。

重复/重叠分析

搜索 repo:rcore-os/tgoskits type:pr state:open kmod OR axbuild OR lkm：

• PR #1231：macOS QEMU/rootfs 鲁棒性改进，不同域，无重复
• PR #984：macOS self-build，无关
• 无重复或冲突风险

阻塞问题

1. 虚拟地址范围约束未实现（os/StarryOS/kernel/src/kmod/mod.rs 第 121 行）：find_free_area() 的搜索范围 VirtAddrRange::new(guard.base(), guard.end()) 仍然是整个内核地址空间，没有将 kmod section 分配限制在 kernel_end 后 2 GiB 范围内。这是 ZR233 在多轮审查中反复指出的核心阻塞点：kmod-loader 对 x86_64 PC32/PLT32、AArch64 branch/page、RISC-V PC-relative、LoongArch branch/PC-relative relocation 都存在范围/overflow 约束。如果模块被分配到超出 PC-relative relocation 可达范围的地址，insmod 会在 relocation 阶段失败。请将 limit 改为 VirtAddrRange::new(kmod_alloc_start, min(kmod_alloc_start + 2GiB, guard.end()))。

2. vmalloc 中仍有 .expect()（第 144 行）：虽然 alloc_kmod_frames 已改用 .ok_or(AxError::NoMemory)?，但 KernelModuleHelper::vmalloc 的 trait 签名返回 Box<dyn SectionMemOps> 而非 Result，所以仍然使用 .expect()。这受 trait 约束暂时无法避免，但建议在上游 kmod-loader 的 vmalloc trait 方法中添加错误返回通道，或在此处添加注释说明约束原因。此问题单独不阻塞，但结合 VA 范围未约束，OOM panic 风险更高。

Powered by mimo-v2.5-pro

done