feat: Add UEFI HTTP boot support#98
Conversation
…action for UEFI loader
…network parameters
|
测试环境: loongarch pc机 
|
…iagnostics for UEFI loader
|
在loongarch-pc机器中传输启动内核成功： 
|
…ing to UEFI loader
![mai-team-app[bot]](https://avatars.githubusercontent.com/u/34859362?s=60&v=4){kind=small}
There was a problem hiding this comment.
PR #98 Review: feat: Add UEFI HTTP Boot support
变更概览
本 PR 为 ostool 添加了 UEFI HTTP Boot 支持，涉及 45 个文件，新增约 9500 行代码。变更覆盖以下几个层次：
- 新增
httpbootcrate：no_std的 UEFI manifest 解析核心库，包含手工 JSON 解析器和 device path URI 提取 - UEFI 应用入口：通过
efi_main实现 UEFI HTTP 协议引导流程（manifest 下载 → kernel 下载 → ExitBootServices → 跳转入口） - loongarch64-uefi-loader：原生 C 加载器（TCP4/TLS/HTTP/manifest 支持）
- ostool-server 端：新增 HTTP Boot 文件服务、HTTPS 静态文件服务器、ProxyDHCP 服务
- ostool CLI 端：新增
run httpboot子命令，完整的上传→引导→会话管理流程
测例变更分析
本 PR 对现有测试行为的影响：
session_ws_lifecycle.rs：最小改动，仅添加了http_boot和proxy_dhcp配置字段到测试用的ServerConfig。这两个字段使用#[serde(default)]，不影响已有的解析行为。config.rs测试：新增board_config_round_trip_supports_uefi_http_boot测试，验证新增的UefiHttpProfile序列化/反序列化。已有测试中新增了http_boot.root_dir相关断言，不影响已有行为。router.rs测试：新增http_boot_upload_manifest_and_public_download_use_board_current_path和http_boot_upload_rejects_non_uefi_http_board两个集成测试，验证 HTTP Boot 文件上传/下载流程。已有测试中BootConfigmatch 分支新增UefiHttp处理（panic），不影响已有逻辑。client.rs测试：新增parse_uefi_http_boot_profile测试。已有BootConfigmatch 分支新增UefiHttp处理。httpbootcrate：12 个单元测试全部通过（本地验证），覆盖 manifest 解析、地址解析、device path URI 提取、边界条件等。http_boot/files.rs：2 个单元测试，验证文件存储路径和路径校验。
结论：对现有行为没有破坏性影响。 所有改动都使用 #[serde(default)] 保证向后兼容，已有 match 分支仅补充了新的变体处理（panic），不改变已有分支行为。
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器实现精简且健壮，错误处理清晰- UEFI ABI 绑定手工编写，结构体布局明确
- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善，防止目录遍历攻击
- HTTPS 静态文件服务器实现简洁，读取请求行和头部有长度限制
- ProxyDHCP 实现完整，包含 arch 匹配、MAC 过滤、IP 校验
建议改进（非阻塞）：
httpboot/src/uefi/http.rs:283—poll_http_token使用 busy-wait 轮询（循环 10万次），建议添加注释说明 UEFI 环境下没有更好的等待机制httpboot/src/uefi/console.rs:10—write_console固定 192 元素 UTF-16 缓冲区，长消息会被静默截断，建议在截断时至少输出...提示ostool-server/src/api/router.rs:76— 短路径/B.EFI、/manifest.json、/kernel.bin使用硬编码 board_id"l"，建议在文档中说明用途ostool-server/src/config.rs:74—HttpBootHttpsConfig默认证书路径，如用户启用 HTTPS 但未创建证书，错误信息较底层，建议增加友好提示ostool-server/src/api/router.rs:1190—put_http_boot_file中读取两次config，两次读取之间配置可能已变，建议复用
CI 状态
所有 CI 检查均已通过：check (stable, x86_64-unknown-linux-gnu) ✅、Release-plz PR ✅、build ✅、deploy ✅
总结
功能完整、测试覆盖良好、对现有行为无破坏性影响。CI 全绿，12 个 httpboot 单元测试本地验证全部通过。建议合并。
Powered by glm-5.1
…ate and arch validation
There was a problem hiding this comment.
PR #98 代码审查：feat: Add UEFI HTTP boot support
变更概览
本 PR 为 ostool 添加了完整的 UEFI HTTP Boot 支持，涉及 46 个文件，约 9500 行新增代码。变更涵盖以下层次：
httpbootcrate：no_std的 UEFI manifest 解析核心库，手工 JSON 解析器 + device path URI 提取，12 个单元测试全部覆盖httpbootUEFI 应用：通过efi_main实现完整的 HTTP Boot 流程（manifest 下载 → kernel 分块下载 → ExitBootServices → 跳转入口），支持boot-jumpfeature gate 控制loongarch64-uefi-loader：原生 C 风格 UEFI 加载器，支持 TCP4 直连 + TLS 加密 + HTTP fallback + 网络 warmup 重试- ostool-server：新增 HTTP Boot 文件服务（上传/下载）、HTTPS 静态文件服务器、ProxyDHCP 服务
- ostool CLI：新增
run httpboot子命令，完整上传 → 引导 → 会话管理流程
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器实现精简，错误处理清晰，12 个单元测试覆盖了所有关键路径- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善，
normalize_relative_path和normalize_board_id防止目录遍历攻击 - HTTPS 静态文件服务器实现简洁，请求行和头部有长度限制（8192 bytes）
- ProxyDHCP 实现完整，包含 arch 匹配、MAC 过滤、IP 校验、vendor class 检测
#[serde(default)]保证新配置字段向后兼容- 架构分离良好：httpboot 独立 no_std 库、server 端 http_boot/files + http_boot/https + proxy_dhcp 模块化
发现的问题
1. 🟡 loongarch64-uefi-loader 中存在硬编码 IP 地址
src/flow.rs:48 和 src/flow.rs:63 中硬编码了 10.3.10.229:3443 和 10.3.10.229 作为 fallback 主机地址。更关键的是 src/tcp4.rs:456 中 HTTP Host 头部硬编码为 10.3.10.229：
// src/tcp4.rs:456
const VERSION_HOST: &[u8] = b" HTTP/1.1\r\nHost: 10.3.10.229\r\nConnection: ";这意味着无论实际服务器地址是什么，HTTP GET 请求都会发送 Host: 10.3.10.229，在多站点部署场景下会导致请求路由错误。建议从 manifest URL 中解析 host 并传入 build_http_get_request。
2. 🟡 cargo fmt 检查不通过
ostool/src/run/httpboot.rs 第 413 行有尾部空白：
UefiBootArch::Other => "other",
}
-
}
3. 🟢 短路径路由硬编码 board_id
/B.EFI、/manifest.json、/kernel.bin 路由使用硬编码 board_id "l"：
async fn get_http_boot_short_loader(State(state): State<AppState>) -> Result<Response, ApiError> {
read_http_boot_current_file(&state, "l", "BOOTLOONGARCH64.EFI").await
}这看起来是 LoongArch 开发调试用的快捷路由。建议添加注释说明用途，或在配置中暴露 board_id。
4. 🟢 Uboot 验证逻辑被移除
本 PR 移除了 UbootProfile::validate()、BoardConfig::validate()、ensure_ipv4()、UbootNetworkMode 以及 normalize_boot_config 中的 uboot 网络验证逻辑。虽然这些改动被 CI 覆盖，但它们的功能影响范围超出了 HTTP Boot 特性。如果这是有意为之的重构，建议在 PR 描述中说明。
5. 🟢 write_console 缓冲区截断无提示
httpboot/src/uefi/console.rs:10 中 write_console 使用 192 元素 UTF-16 缓冲区，长消息会被静默截断。建议在截断时至少输出 ... 提示。
测试覆盖
httpbootcrate：12 个单元测试（manifest 解析、地址解析、device path URI、边界条件）http_boot/files.rs：2 个测试（文件存储路径、路径校验）router.rs：新增 HTTP Boot 上传/下载集成测试config.rs：新增UefiHttpProfile序列化/反序列化测试- 已有测试中
BootConfig::UefiHttp分支添加 panic 占位，不影响已有行为
CI 状态
CI 检查已全部通过（check、build、deploy、Release-plz）。
总结
功能完整、架构清晰、测试覆盖良好。对现有行为无破坏性影响（#[serde(default)] 保证向后兼容）。主要建议：修复 loongarch64-uefi-loader 中的硬编码 IP 地址问题以及 cargo fmt 格式问题。建议合并。
Powered by mimo-v2.5-pro
There was a problem hiding this comment.
PR #98 审查：feat: Add UEFI HTTP boot support
变更概览
本 PR 为 ostool 添加了完整的 UEFI HTTP Boot 支持，涉及 47 个文件，新增 9616 行代码。变更覆盖：
httpbootcrate：no_stdUEFI manifest 解析核心库，12 个单元测试覆盖全面httpbootUEFI 应用：完整的 HTTP Boot 流程（manifest 下载 → kernel 分块下载 → ExitBootServices → 跳转入口）loongarch64-uefi-loader：原生 C 风格 UEFI 加载器，支持 TCP4 + TLS + HTTP- ostool-server：HTTP Boot 文件服务、HTTPS 静态服务器、ProxyDHCP 服务
- ostool CLI：
run httpboot子命令
CI 状态
所有 CI 检查已通过（check、build、deploy、Release-plz）✅
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器精简健壮，错误处理清晰，测试覆盖全面- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善（
normalize_relative_path+normalize_board_id），防止目录遍历攻击 - ProxyDHCP 实现完整，包含 arch 匹配、MAC 过滤、vendor class 检测
- 新配置字段使用
#[serde(default)]，保证向后兼容性 - 已在 loongarch 实机上验证成功启动内核
发现的问题
⚠️ 1. 破坏性变更：移除了 Uboot 网络配置字段
本 PR 从 UbootProfile 中移除了以下字段：
kernel_load_addr、fit_load_addr、bootm_addrnetwork_mode、board_ip、server_ip、netmask、gatewayip- 同时删除了
UbootNetworkMode枚举、UbootProfile::validate()、BoardConfig::validate()和ensure_ipv4()函数
由于 UbootProfile 标记了 #[serde(deny_unknown_fields)]，任何包含上述字段的现有 board 配置文件将解析失败。例如：
[boot]
kind = "uboot"
network_mode = "dhcp" # 将导致反序列化错误网络配置似乎已迁移至 server 级别的 TftpNetworkConfig，但此变更属于破坏性变更，建议：
- 在 PR 描述或 commit 中说明此变更
- 考虑提供一个迁移指南或兼容性说明
- 或者至少在 release notes 中标注
⚠️ 2. cargo fmt 格式问题
ostool/src/run/httpboot.rs:413 — 存在尾部空白字符，cargo fmt --check 报错：
Diff in /workspace/repo/ostool/src/run/httpboot.rs:413:
UefiBootArch::Other => "other",
}
-
}
⚠️ 3. loongarch64-uefi-loader 硬编码 IP 地址
flow.rs:48,63 和 tcp4.rs:456 硬编码了 10.3.10.229：
// tcp4.rs:456
const VERSION_HOST: &[u8] = b" HTTP/1.1\r\nHost: 10.3.10.229\r\nConnection: ";这意味着无论实际服务器地址是什么，HTTP 请求的 Host 头部始终为 10.3.10.229。这显然是开发/测试环境的残留。建议从 manifest URL 中解析 host 并传入 build_http_get_request。
建议（非阻塞）：
- 硬编码 board_id：
/B.EFI、/manifest.json、/kernel.bin路由使用硬编码 board_id"l"，建议添加注释说明用途 - 控制台缓冲区截断：
httpboot/src/uefi/console.rs中write_console在 192 字符处静默截断消息，建议至少输出...提示 - TOCTOU：
put_http_boot_file函数两次读取state.config，两次读取之间配置可能已变，建议合并为一次读取
总结
功能完整、测试覆盖良好、CI 全绿、已在 loongarch 实机上验证成功。主要关注点是 Uboot 网络字段的破坏性移除和 cargo fmt 格式问题。建议合并且在上线前确认 Uboot 配置兼容性。
Powered by deepseek-v4-pro
There was a problem hiding this comment.
PR #98 代码审查：feat: Add UEFI HTTP boot support
变更概览
本 PR 为 ostool 添加了完整的 UEFI HTTP Boot 支持，涉及 113 个文件，新增约 10000 行代码。变更涵盖以下层次：
httpbootcrate：no_std的 UEFI manifest 解析核心库，手工 JSON 解析器 + device path URI 提取，12 个单元测试全部通过httpbootUEFI 应用：完整的 HTTP Boot 流程（manifest 下载 → kernel 分块下载 → ExitBootServices → 跳转入口），支持 HTTP Range 请求loongarch64-uefi-loader：原生 UEFI 加载器，支持 TCP4 直连 + TLS 加密 + HTTP fallback + 网络 warmup 重试- ostool-server：新增 HTTP Boot 文件服务（上传/下载）、HTTPS 静态文件服务器、ProxyDHCP 服务
- ostool CLI：新增
run httpboot子命令，完整上传 → 引导 → 会话管理流程
验证结果
| 检查项 | 结果 |
|---|---|
cargo fmt --check |
✅ 通过 |
httpboot crate 单元测试 |
✅ 12/12 通过 |
完整构建（cargo test --no-run） |
ostool-server 构建 |
| 与 main 的合并 |
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器实现精简健壮，边界条件处理完善（空 body、过大 body、非 UTF-8、转义字符串等均有测试覆盖）- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善（
normalize_relative_path+normalize_board_id），防止目录遍历攻击 - ProxyDHCP 实现完整，包含 arch 匹配（X86_64/Aarch64/Loongarch64）、MAC 过滤、vendor class 检测、IP 校验
- HTTPS 静态文件服务器实现简洁，请求行和头部有长度限制（8192 bytes）
- 新配置字段使用
#[serde(default)]，保证向后兼容性 - HTTP Range 请求支持，实现 kernel 分块下载
- 架构分离良好：httpboot 独立 no_std 库、server 端模块化清晰
发现的问题
⚠️ 1. 破坏性变更：UbootProfile 字段移除
本 PR 从 UbootProfile 中移除了以下字段：kernel_load_addr、fit_load_addr、bootm_addr、network_mode、board_ip、server_ip、netmask、gatewayip。同时删除了 UbootNetworkMode 枚举、UbootProfile::validate()、BoardConfig::validate() 和 ensure_ipv4() 函数。
由于 UbootProfile 标记了 #[serde(deny_unknown_fields)]，任何包含上述字段的现有 board 配置文件将直接解析失败。网络配置似乎已迁移至 server 级别的 TftpNetworkConfig，但此变更属于破坏性变更，建议在 PR 描述或 release notes 中说明迁移路径。
⚠️ 2. loongarch64-uefi-loader 硬编码 IP 地址
三处硬编码 10.3.10.229：
flow.rs:48— fallback 主机10.3.10.229:3443flow.rs:63— fallback 主机10.3.10.229tcp4.rs:456— HTTPHost头部固定为Host: 10.3.10.229，无论实际服务器地址是什么
tcp4.rs:456 的硬编码最为关键：
const VERSION_HOST: &[u8] = b" HTTP/1.1\r\nHost: 10.3.10.229\r\nConnection: ";这意味着 HTTP GET 请求始终发送 Host: 10.3.10.229，在非目标环境中会导致请求路由错误。建议从 manifest URL 中解析 host 并传入 build_http_get_request。flow.rs 中的 fallback 地址在开发阶段可以接受，但建议后续改为可配置。
🟢 3. 短路由硬编码 board_id
/B.EFI、/manifest.json、/kernel.bin 路由使用硬编码 board_id "l"（LoongArch 开发调试用快捷路由）。建议添加注释说明用途。
🟢 4. write_console 缓冲区截断无提示
httpboot/src/uefi/console.rs 中 write_console 使用 192 元素 UTF-16 缓冲区，长消息会被静默截断。建议在截断时输出 ... 提示。
🟢 5. put_http_boot_file 中双重读取配置
router.rs 中 put_http_boot_file 函数两次读取 state.config，两次读取之间配置可能已变。建议复用单次读取结果。
总结
功能完整、架构清晰、测试覆盖良好。httpboot crate 的 12 个单元测试全部通过，cargo fmt --check 通过。主要关注点是 Uboot 网络字段的破坏性移除（需在文档中说明迁移路径）和 loongarch64-uefi-loader 中的硬编码 IP 地址（特别是 HTTP Host 头部）。
当前 PR 与 main 存在合并冲突（6 个文件），需要作者 rebase 后再合并。
建议合并（待解决合并冲突后）。
Powered by Mai
Powered by mimo-v2.5-pro
There was a problem hiding this comment.
PR #98 代码审查：feat: Add UEFI HTTP boot support
变更概览
本 PR 为 ostool 添加了完整的 UEFI HTTP Boot 支持，涉及 112 个文件，新增约 11400 行代码。变更涵盖以下层次：
httpbootcrate：no_std的 UEFI manifest 解析核心库，手工 JSON 解析器 + device path URI 提取，12 个单元测试全部通过 ✅httpbootUEFI 应用：完整的 HTTP Boot 流程（manifest 下载 → kernel 分块下载 → ExitBootServices → 跳转入口），支持 HTTP Range 请求loongarch64-uefi-loader：原生 UEFI 加载器，支持 TCP4 直连 + TLS 加密 + HTTP fallback + 网络 warmup 重试- ostool-server：新增 HTTP Boot 文件服务（上传/下载）、HTTPS 静态文件服务器、ProxyDHCP 服务
- ostool CLI：新增
run httpboot子命令，完整上传 → 引导 → 会话管理流程
验证结果
| 检查项 | 结果 |
|---|---|
cargo fmt --check |
✅ 通过 |
httpboot crate 单元测试 |
✅ 12/12 通过 |
| 与 main 合并 | ❌ 4 个文件存在冲突 |
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器实现精简健壮，边界条件处理完善- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善（
normalize_relative_path+normalize_board_id），防止目录遍历攻击 - ProxyDHCP 实现完整，包含 arch 匹配（X86_64/Aarch64/Loongarch64）、MAC 过滤、vendor class 检测
- HTTPS 静态文件服务器实现简洁，请求行和头部有长度限制（8192 bytes）
- 新配置字段使用
#[serde(default)]，保证向后兼容性 - HTTP Range 请求支持，实现 kernel 分块下载
- 架构分离良好：httpboot 独立 no_std 库、server 端模块化清晰
需要解决的问题
⚠️ 1. 合并冲突
当前 PR 与 main 分支存在 4 个文件的合并冲突：
ostool-server/src/api/router.rsostool-server/src/config.rsostool-server/src/lib.rsostool-server/tests/session_ws_lifecycle.rs
需要 rebase 或 merge main 后才能合并。
⚠️ 2. UbootProfile 破坏性变更
本 PR 从 UbootProfile（标记了 #[serde(deny_unknown_fields)]）中移除了以下字段：
kernel_load_addr、fit_load_addr、bootm_addrnetwork_mode、board_ip、server_ip、netmask、gatewayip
同时删除了 UbootNetworkMode 枚举和 UbootProfile::validate() 函数。
由于 deny_unknown_fields 的存在，任何包含上述字段的现有 board 配置文件将直接解析失败。建议：
- 在 PR 描述或 release notes 中说明此破坏性变更
- 提供迁移指南（说明网络配置已迁移至 server 级别的
TftpNetworkConfig）
⚠️ 3. loongarch64-uefi-loader 硬编码 IP 地址
三处硬编码 10.3.10.229：
flow.rs:48— fallback 主机10.3.10.229:3443flow.rs:63— fallback 主机10.3.10.229tcp4.rs:456— HTTPHost头部固定为Host: 10.3.10.229
tcp4.rs:456 的硬编码最为关键：
const VERSION_HOST: &[u8] = b" HTTP/1.1\r\nHost: 10.3.10.229\r\nConnection: ";这意味着 HTTP GET 请求始终发送 Host: 10.3.10.229，在非目标环境中会导致请求路由错误。建议从 manifest URL 中解析 host 并传入 build_http_get_request。
🟢 4. 短路由硬编码 board_id
/B.EFI、/manifest.json、/kernel.bin 路由使用硬编码 board_id "l"（LoongArch 开发调试用快捷路由）。建议添加注释说明用途，或在配置中暴露 board_id。
🟢 5. write_console 缓冲区截断无提示
httpboot/src/uefi/console.rs 中 write_console 使用 192 元素 UTF-16 缓冲区，长消息会被静默截断。建议在截断时输出 ... 提示。由于同时输出到 COM1 串口，串口日志不受影响。
总结
功能完整、架构清晰、测试覆盖良好。httpboot crate 的 12 个单元测试全部通过，cargo fmt --check 通过。主要需要解决：
- 合并冲突（4 个文件）
- UbootProfile 破坏性变更需文档说明迁移路径
- loongarch64-uefi-loader 中的硬编码 IP（特别是 HTTP Host 头部）
建议合并且在上线前解决上述问题。
Powered by Mai
Powered by mimo-v2.5-pro
There was a problem hiding this comment.
PR #98 代码审查：feat: Add UEFI HTTP Boot support
变更概览
本 PR 为 ostool 添加完整的 UEFI HTTP Boot 支持，涉及 47 个文件，新增约 10163 行代码。变更涵盖：
httpbootcrate：no_stdUEFI manifest 解析核心库，手工 JSON 解析器 + device path URI 提取httpbootUEFI 应用：完整的 HTTP Boot 流程（manifest 下载 → kernel 分块下载 → ExitBootServices → 跳转入口）loongarch64-uefi-loader：原生 UEFI 加载器，支持 TCP4 直连 + TLS 加密 + HTTP fallback + 网络 warmup 重试- ostool-server：新增 HTTP Boot 文件服务、HTTPS 静态文件服务器、ProxyDHCP 服务
- ostool CLI：新增
run httpboot子命令
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器实现精简健壮，错误处理清晰- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善（
normalize_relative_path+normalize_board_id），防止目录遍历攻击 - ProxyDHCP 实现完整，包含 arch 匹配、MAC 过滤、vendor class 检测
- HTTPS 静态文件服务器实现简洁，请求行和头部有长度限制
- 新配置字段使用
#[serde(default)]，保证向后兼容性 - 架构分离良好：httpboot 独立 no_std 库、server 端模块化清晰
ostool-server编译通过 ✅
需要修复的问题
🔴 1. 合并冲突
当前 PR 与 main 存在合并冲突（mergeable_state: dirty），无法直接合并。需要 rebase 或 merge main。
🔴 2. 测试编译失败
cargo test -p ostool-server 编译失败：
error: couldn't read `ostool-server/src/../../docs/examples/Asus-nuc15-x86_64-vmx.board.toml`: No such file or directory
--> ostool-server/src/config.rs:768:23
新增的测试 asus_nuc15_x86_64_vmx_example_board_config_parses 引用了 docs/examples/Asus-nuc15-x86_64-vmx.board.toml，但该文件未在 PR 中提交。需要添加此示例文件，或将测试改为不依赖外部文件。
🟡 3. loongarch64-uefi-loader 中硬编码 IP 地址
三处硬编码 10.3.10.229：
tcp4.rs:456— HTTPHost头部固定为Host: 10.3.10.229，无论实际服务器地址是什么flow.rs:48— fallback 主机10.3.10.229:3443flow.rs:63— fallback 主机10.3.10.229
tcp4.rs 中的问题最为关键：
const VERSION_HOST: &[u8] = b" HTTP/1.1\r\nHost: 10.3.10.229\r\nConnection: ";HTTP GET 请求始终发送 Host: 10.3.10.229，在非目标环境会导致请求路由错误。建议从 URL 中动态解析 host 并传入 build_http_get_request。
🟡 4. UbootProfile 破坏性变更
本 PR 从 UbootProfile 中移除了多个字段（kernel_load_addr、fit_load_addr、bootm_addr、network_mode、board_ip、server_ip、netmask、gatewayip）。由于 UbootProfile 标记了 #[serde(deny_unknown_fields)]，任何包含这些字段的现有 board 配置文件将直接解析失败。建议在 PR 描述中说明此变更并提供迁移指南。
建议（非阻塞）
/B.EFI、/manifest.json、/kernel.bin短路由使用硬编码 board_id"l"，建议添加注释说明用途write_console使用 192 元素 UTF-16 缓冲区，长消息会被静默截断，建议输出截断提示put_http_boot_file中两次读取state.config，两次读取之间配置可能已变，建议复用
总结
功能完整、架构清晰，整体代码质量良好。需要修复的关键问题：
- 解决合并冲突
- 补充缺失的示例文件或修复测试
- 修复
loongarch64-uefi-loader中的硬编码 IP 地址（特别是 HTTP Host 头部）
建议修复上述问题后合并。
Powered by mimo-v2.5-pro
There was a problem hiding this comment.
PR #98 代码审查：feat: Add UEFI HTTP Boot support
变更概览
本 PR 为 ostool 添加完整的 UEFI HTTP Boot 支持，涉及 47 个文件，新增约 9834 行代码。变更涵盖：
httpbootcrate：no_stdUEFI manifest 解析核心库，手工 JSON 解析器 + device path URI 提取httpbootUEFI 应用：完整的 HTTP Boot 流程（manifest 下载 → kernel 分块下载 → ExitBootServices → 跳转入口）loongarch64-uefi-loader：原生 UEFI 加载器，支持 TCP4 直连 + TLS 加密 + HTTP fallback + 网络 warmup 重试- ostool-server：新增 HTTP Boot 文件服务、HTTPS 静态文件服务器、ProxyDHCP 服务
- ostool CLI：新增
run httpboot子命令
本地验证结果
| 检查项 | 结果 |
|---|---|
cargo fmt --check |
✅ 通过 |
httpboot crate 单元测试 |
✅ 12/12 通过 |
| 与 main 合并 | ❌ 严重冲突（main 新增 20 个提交） |
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器实现精简健壮，12 个单元测试覆盖全面- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善（
normalize_relative_path+normalize_board_id），防止目录遍历攻击 - ProxyDHCP 实现完整，包含 arch 匹配、MAC 过滤、vendor class 检测、IP 校验
- HTTPS 静态文件服务器实现简洁，请求行和头部有长度限制（8192 bytes）
- 新配置字段使用
#[serde(default)]，保证向后兼容性 - HTTP Range 请求支持，实现 kernel 分块下载
- 架构分离良好：httpboot 独立 no_std 库、server 端模块化清晰
需要修复的问题
⚠️ 1. 严重合并冲突
PR 的 base commit (7fa6564) 以来，main 分支新增了 20 个提交，包括：
78ac8befeat: 添加 U-Boot 网络模式配置（DHCP/静态IP）— 重新添加了本 PR 移除的 UbootProfile 网络字段3ecff3cfeat(ostool): support board-specific U-Boot load addresses93db64fAdd board-specific U-Boot load address configuration to ostool-server663ee70refactor(tool): 拆分运行入口与 Tool facade- 等多个重构提交
Cargo.lock、ostool-server/src/config.rs、ostool-server/src/api/router.rs、ostool-server/src/lib.rs、ostool-server/tests/session_ws_lifecycle.rs、ostool/src/main.rs 等 11 个文件存在冲突。
特别注意语义冲突：
- PR 分支的
UbootProfile已移除kernel_load_addr、fit_load_addr、bootm_addr、network_mode、board_ip、server_ip、netmask、gatewayip字段 - main 分支在 commit
78ac8be中重新添加了这些字段（含UbootNetworkMode枚举和validate()函数） - 两分支对同一结构体的修改方向相反，合并时需要仔细处理
⚠️ 2. 测试编译失败：缺少示例文件
ostool-server/src/config.rs:768 新增测试 asus_nuc15_x86_64_vmx_example_board_config_parses 使用了 include_str!("../../docs/examples/Asus-nuc15-x86_64-vmx.board.toml")，但该文件在 PR 分支和 main 分支中均不存在。include_str! 是编译期宏，会导致编译失败。
⚠️ 3. loongarch64-uefi-loader 硬编码 IP 地址
三处硬编码 10.3.10.229：
tcp4.rs:456— HTTPHost头部固定为Host: 10.3.10.229，无论实际服务器地址是什么flow.rs:48— fallback 主机10.3.10.229:3443flow.rs:63— fallback 主机10.3.10.229
tcp4.rs 中的问题最为关键：
const VERSION_HOST: &[u8] = b" HTTP/1.1\r\nHost: 10.3.10.229\r\nConnection: ";HTTP GET 请求始终发送 Host: 10.3.10.229，在非目标环境会导致请求路由错误。建议从 URL 中动态解析 host 并传入 build_http_get_request。
建议（非阻塞）
/B.EFI、/manifest.json、/kernel.bin短路由使用硬编码 board_id"l"（LoongArch 开发调试用），建议添加注释说明write_console使用 192 元素 UTF-16 缓冲区，长消息会被静默截断，建议输出截断提示put_http_boot_file中两次读取state.config，两次读取之间配置可能已变，建议复用
总结
功能完整、架构清晰、httpboot crate 测试覆盖良好。但当前 PR 无法合并，需要：
- Rebase 到最新 main — 特别是解决
UbootProfile的语义冲突（main 已重新添加网络字段） - 补充缺失的示例文件
docs/examples/Asus-nuc15-x86_64-vmx.board.toml或删除该测试 - 修复
loongarch64-uefi-loader中的硬编码 IP 地址（特别是 HTTP Host 头部）
建议修复上述问题后合并。
Powered by mimo-v2.5-pro
…extOutput ABI fields
There was a problem hiding this comment.
PR #98 代码审查：feat: Add UEFI HTTP Boot support
变更概览
本 PR 为 ostool 添加完整的 UEFI HTTP Boot 支持，涉及 47 个文件，新增约 9856 行代码。变更涵盖：
httpbootcrate：no_stdUEFI manifest 解析核心库，手工 JSON 解析器 + device path URI 提取，12 个单元测试httpbootUEFI 应用：完整的 HTTP Boot 流程（manifest 下载 → kernel 分块下载 → ExitBootServices → 跳转入口），支持 HTTP Range 请求loongarch64-uefi-loader：原生 UEFI 加载器，支持 TCP4 直连 + TLS 加密 + HTTP fallback + 网络 warmup 重试- ostool-server：新增 HTTP Boot 文件服务（上传/下载）、HTTPS 静态文件服务器、ProxyDHCP 服务
- ostool CLI：新增
run httpboot子命令
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器实现精简健壮，错误处理清晰，12 个单元测试覆盖全面- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善（
normalize_relative_path+normalize_board_id），防止目录遍历攻击 - ProxyDHCP 实现完整，包含 arch 匹配（X86_64/Aarch64/Loongarch64）、MAC 过滤、vendor class 检测
- HTTPS 静态文件服务器实现简洁，请求行和头部有长度限制（8192 bytes）
- 新配置字段使用
#[serde(default)]，保证向后兼容性 - HTTP Range 请求支持，实现 kernel 分块下载，带进度条和重试逻辑
- 架构分离良好：httpboot 独立 no_std 库、server 端模块化清晰
- UEFI HTTP 协议封装完整，Host 头部正确从 URL 中动态解析
需要修复的问题
🔴 1. 测试编译失败：缺少示例文件
ostool-server/src/config.rs 中的测试 asus_nuc15_x86_64_vmx_example_board_config_parses 使用了 include_str!("../../docs/examples/Asus-nuc15-x86_64-vmx.board.toml")，但该文件在 PR 分支中不存在（include_str! 是编译期宏，文件不存在将直接导致编译失败）。
建议：添加 docs/examples/Asus-nuc15-x86_64-vmx.board.toml 示例文件，或将测试改为使用内联字符串。
🟡 2. 合并冲突
当前 PR 与 main 存在 6 个文件的合并冲突（router.rs、config.rs、lib.rs、session_ws_lifecycle.rs、main.rs、menuconfig.rs）。main 自 PR 的 base commit 以来新增了 20+ 个提交，包括 U-Boot 网络模式配置、board-specific U-Boot load addresses、Tool facade 重构等。需要 rebase 到最新 main 解决冲突。
🟡 3. loongarch64-uefi-loader 硬编码 IP 地址
三处硬编码 10.3.10.229：
tcp4.rs:456— HTTPHost头部固定为Host: 10.3.10.229，无论实际服务器地址是什么flow.rs:48— fallback 主机10.3.10.229:3443flow.rs:63— fallback 主机10.3.10.229
tcp4.rs 中的问题最为关键：
const VERSION_HOST: &[u8] = b" HTTP/1.1\r\nHost: 10.3.10.229\r\nConnection: ";HTTP GET 请求始终发送 Host: 10.3.10.229，在非目标环境会导致请求路由错误。建议从 URL 中动态解析 host 并传入 build_http_get_request。（注：httpboot crate 的 UEFI 应用已正确实现了动态 Host 解析。）
建议（非阻塞）
call_entry_point缺少 loongarch64 实现：httpboot/src/uefi/entry.rs中call_entry_point仅有 x86_64/aarch64/riscv64 的实现，loongarch64 走 catch-all 分支（无限循环）。虽然 loongarch64 平台使用独立的loongarch64-uefi-loader，但建议添加 loongarch64 实现或在编译时给出提示。- 短路由硬编码 board_id：
/B.EFI、/manifest.json、/kernel.bin路由使用硬编码 board_id"l"（LoongArch 开发调试用快捷路由），建议添加注释说明用途。 write_console缓冲区截断无提示：192 元素 UTF-16 缓冲区在长消息时静默截断，建议输出...提示。由于同时输出到 COM1 串口，串口日志不受影响。put_http_boot_file中双重读取配置：两次读取state.config之间配置可能已变，建议复用单次读取。
总结
功能完整、架构清晰、测试覆盖良好。httpboot crate 的 12 个单元测试覆盖了所有关键路径。主要需要修复：
- 补充缺失的示例文件
docs/examples/Asus-nuc15-x86_64-vmx.board.toml（否则测试编译失败） - Rebase 到最新 main 解决合并冲突
- 修复
loongarch64-uefi-loader中的硬编码 IP 地址（特别是 HTTP Host 头部）
建议修复上述问题后合并。
Powered by Mai
Powered by mimo-v2.5-pro
There was a problem hiding this comment.
PR #98 代码审查：feat: Add UEFI HTTP boot support
变更概览
本 PR 为 ostool 添加完整的 UEFI HTTP Boot 支持，涉及 47 个文件，38 个提交，新增约 9856 行代码。变更涵盖：
httpbootcrate：no_stdUEFI manifest 解析核心库，手工 JSON 解析器 + device path URI 提取，12 个单元测试全部通过 ✅httpbootUEFI 应用：完整的 HTTP Boot 流程（manifest 下载 → kernel 分块下载 → ExitBootServices → 跳转入口），支持 HTTP Range 请求loongarch64-uefi-loader：原生 UEFI 加载器，支持 TCP4 直连 + TLS 加密 + HTTP fallback + 网络 warmup 重试- ostool-server：新增 HTTP Boot 文件服务（上传/下载）、HTTPS 静态文件服务器、ProxyDHCP 服务
- ostool CLI：新增
run httpboot子命令，完整上传 → 引导 → 会话管理流程
本地验证结果
| 检查项 | 结果 |
|---|---|
cargo fmt --check |
✅ 通过 |
httpboot crate 单元测试 |
✅ 12/12 通过 |
| 与 main 合并 | ❌ 6 个文件存在冲突 |
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器实现精简健壮，边界条件处理完善- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善（
normalize_relative_path+normalize_board_id），防止目录遍历攻击 - ProxyDHCP 实现完整，包含 arch 匹配（X86_64/Aarch64/Loongarch64）、MAC 过滤、vendor class 检测、IP 校验
- HTTPS 静态文件服务器实现简洁，请求行和头部有长度限制（8192 bytes）
- 新配置字段使用
#[serde(default)]，保证向后兼容性 - HTTP Range 请求支持，实现 kernel 分块下载
- 架构分离良好：httpboot 独立 no_std 库、server 端模块化清晰
需要修复的问题
⚠️ 1. 合并冲突（6 个文件）
当前 PR 与 main 存在合并冲突，无法直接合并。自 PR 的 base commit (7fa6564) 以来，main 新增了 20 个提交。冲突文件：
ostool-server/src/api/router.rsostool-server/src/config.rsostool-server/src/lib.rsostool-server/tests/session_ws_lifecycle.rsostool/src/main.rsostool/src/menuconfig.rs
特别注意语义冲突：
- PR 分支的
UbootProfile仅保留use_tftp和dtb_name两个字段 - main 分支在
78ac8be中重新添加了kernel_load_addr、fit_load_addr、bootm_addr、network_mode、board_ip、server_ip、netmask、gatewayip字段及UbootNetworkMode枚举 - 两分支对同一结构体的修改方向相反，合并时需要仔细处理
⚠️ 2. loongarch64-uefi-loader 硬编码 IP 地址
三处硬编码 10.3.10.229：
tcp4.rs:456— HTTPHost头部固定为Host: 10.3.10.229，无论实际服务器地址是什么flow.rs:48— fallback 主机10.3.10.229:3443flow.rs:63— fallback 主机10.3.10.229
tcp4.rs 中的问题最为关键：
const VERSION_HOST: &[u8] = b" HTTP/1.1\r\nHost: 10.3.10.229\r\nConnection: ";HTTP GET 请求始终发送 Host: 10.3.10.229，在非目标环境会导致请求路由错误。建议从 URL 中动态解析 host 并传入 build_http_get_request。flow.rs 中的 fallback 地址在开发阶段可接受，但建议后续改为可配置。
⚠️ 3. UbootProfile 字段移除
本 PR 从 UbootProfile 中移除了多个字段。虽然 UbootProfile 未标记 deny_unknown_fields（所以不会导致解析失败），但已有配置中的这些字段将被静默忽略，行为发生变化。建议在 PR 描述或 commit message 中明确说明此变更及迁移路径。
建议（非阻塞）
- 短路由硬编码 board_id：
/B.EFI、/manifest.json、/kernel.bin路由使用硬编码 board_id"l"（LoongArch 开发调试用快捷路由），建议添加注释说明用途 - 控制台缓冲区截断：
httpboot/src/uefi/console.rs中write_console使用 192 元素 UTF-16 缓冲区，长消息会被静默截断，建议至少输出...提示。由于同时输出到 COM1 串口，完整日志不受影响 - 双重配置读取：
put_http_boot_file中两次读取state.config，建议复用单次读取结果
总结
功能完整、架构清晰、测试覆盖良好。httpboot crate 的 12 个单元测试全部通过，cargo fmt --check 通过。ProxyDHCP 和文件服务实现质量高。
当前 PR 需要解决以下问题后才能合并：
- Rebase 到最新 main，特别是处理
UbootProfile的语义冲突 - 修复
loongarch64-uefi-loader中的硬编码 IP 地址（特别是 HTTP Host 头部）
建议修复后合并。
Powered by mimo-v2.5-pro
There was a problem hiding this comment.
PR #98 代码审查：feat: Add UEFI HTTP Boot support
变更概览
本 PR 为 ostool 添加完整的 UEFI HTTP Boot 支持，涉及 113 个文件，新增约 11671 行代码。变更涵盖：
httpbootcrate（~2367 行）：no_stdUEFI manifest 解析核心库，手工 JSON 解析器 + device path URI 提取，12 个单元测试全部通过 ✅httpbootUEFI 应用：完整的 HTTP Boot 流程（manifest 下载 → kernel 分块下载 → ExitBootServices → 跳转入口），支持 HTTP Range 请求loongarch64-uefi-loader：原生 UEFI 加载器，支持 TCP4 直连 + TLS 加密 + HTTP fallback + 网络 warmup 重试- ostool-server：新增 HTTP Boot 文件服务（上传/下载）、HTTPS 静态文件服务器、ProxyDHCP 服务
- ostool CLI：新增
run httpboot子命令，完整上传 → 引导 → 会话管理流程
本地验证结果
| 检查项 | 结果 |
|---|---|
cargo fmt --check |
❌ 未通过 |
httpboot crate 单元测试 |
✅ 12/12 通过 |
| 与 main 合并 | ❌ 6 个文件存在冲突 |
docs/examples/Asus-nuc15-x86_64-vmx.board.toml |
❌ 文件缺失 |
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器实现精简健壮，边界条件处理完善（空 body、过大 body、非 UTF-8、转义字符串等均有测试覆盖）- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善（
normalize_relative_path+normalize_board_id），防止目录遍历攻击 - ProxyDHCP 实现完整，包含 arch 匹配（X86_64/Aarch64/Loongarch64）、MAC 过滤、vendor class 检测、IP 校验
- HTTPS 静态文件服务器实现简洁，请求行和头部有长度限制（8192 bytes）
- 新配置字段使用
#[serde(default)]，保证向后兼容性 - HTTP Range 请求支持，实现 kernel 分块下载
- 架构分离良好：httpboot 独立 no_std 库、server 端模块化清晰
- 已在 loongarch 实机上验证成功启动内核
需要修复的问题
🔴 1. 合并冲突（6 个文件）
PR 的 base commit (7fa6564) 以来，main 分支新增了 20+ 个提交，包括 UbootNetworkMode 配置支持、重构 Tool facade 等。以下文件存在冲突：
ostool-server/src/api/router.rsostool-server/src/config.rsostool-server/src/lib.rsostool-server/tests/session_ws_lifecycle.rsostool/src/main.rsostool/src/menuconfig.rs
特别注意语义冲突：main 分支已在 78ac8be 中为 UbootProfile 重新添加了 kernel_load_addr、fit_load_addr、bootm_addr、network_mode 等字段和 UbootNetworkMode 枚举。本 PR 移除了这些字段。两分支对同一结构体的修改方向相反，需要仔细处理。
🔴 2. 测试编译失败：缺少示例文件
ostool-server/src/config.rs:768 使用了 include_str!("../../docs/examples/Asus-nuc15-x86_64-vmx.board.toml")，但该文件在 PR 分支和 main 分支中均不存在。include_str! 是编译期宏，会导致 ostool-server 整体编译失败。
// config.rs:768
let content = include_str!("../../docs/examples/Asus-nuc15-x86_64-vmx.board.toml");🔴 3. cargo fmt 格式问题
httpboot/src/uefi/http.rs:878 存在格式不一致：
// 当前代码
let response = receive_kernel_stream_chunk(
console,
boot_services,
http_protocol,
body,
body_len,
first,
)?;
// fmt 要求
let response =
receive_kernel_stream_chunk(console, boot_services, http_protocol, body, body_len, first)?;🟡 4. loongarch64-uefi-loader 硬编码 IP 地址
三处硬编码 10.3.10.229：
tcp4.rs:456— HTTPHost头部固定为Host: 10.3.10.229，无论实际服务器地址是什么flow.rs:48— fallback 主机10.3.10.229:3443flow.rs:63— fallback 主机10.3.10.229
tcp4.rs 中的问题最为关键：
const VERSION_HOST: &[u8] = b" HTTP/1.1\r\nHost: 10.3.10.229\r\nConnection: ";HTTP GET 请求始终发送 Host: 10.3.10.229，在非目标环境会导致请求路由错误。建议从 URL 中动态解析 host 并传入 build_http_get_request。
🟡 5. BoardRunConfig 移除字段
PR 从 BoardRunConfig（ostool/src/board/config.rs）中移除了 kernel_load_addr、fit_load_addr、bootm_addr 字段。虽然没有 deny_unknown_fields 属性，旧配置文件不会报错，但这些字段会被静默忽略。同时 main 分支已通过其他 PR 重新添加了这些字段，建议在 PR 描述中说明此变更的意图和迁移路径。
建议（非阻塞）
/B.EFI、/manifest.json、/kernel.bin短路由使用硬编码 board_id"l"（LoongArch 开发调试用），建议添加注释说明用途write_console使用 192 元素 UTF-16 缓冲区，长消息会被静默截断，建议输出截断提示（串口日志不受影响）put_http_boot_file中两次读取state.config，建议复用
总结
功能完整、架构清晰、httpboot crate 测试覆盖良好、已在 loongarch 实机上验证成功。但当前 PR 存在以下必须修复的问题：
- 合并冲突（6 个文件）
- 缺少示例文件导致
ostool-server编译失败 cargo fmt未通过
建议修复上述问题后合并。
Powered by mimo-v2.5-pro
1 participant
No description provided.