- Vexilon
- 付锦鹏
- 杨邵恺
- 陈安达
- 邱义家
- 李俊谕
- 课程：OSH-2026 操作系统课程设计
- 学期：2026 春季学期
- 单位：中国科学技术大学
| 项目阶段 | 日期 | 项目进展 |
|---|---|---|
| 选题探索 | 3.4 ~ 3.15 | 组内成员线下开展研讨会分析往年小组选题，提出1.增强型LLm嵌入文件系统、2.Rust改写系统内核、3.网络协议栈改写等多种选择 |
| 3.16 ~ 3.18 | 组内成员锁定Rust重写项目并对重写哪种具体系统开展探索 | |
| 项目调研 | 3.19 ~ 3.29 | 通过比较多种选择，并于老师和助教进行激烈的线上讨论后，最终选定LiteOS-M |
| 路线收敛 | 3.30 ~ 4.1 | 与老师进行线下研讨，确定“LiteOs-M核心模块接力重构 + IronClaw 接口层”最终路线 |
| 报告撰写 | 4.6 ~ 4.19 | 开展项目仓库主页README、调研报告、可行性报告、项目介绍ppt的写作任务并在过程中不断修正错误、加深对任务理解 |
| 报告改进 | 4.19 ~ 4.27 | 经过课上老师对本小组工作的点评，新增选择开发板并实际上板验证工作，本周完成此任务的多报告内容补充 |
| 项目第一阶段 | 4.28 ~ 5.26 | 完成rust化los_membox.c (10KB), los_task.c (50KB), los_tick.c (15KB), los_sortlink.c (6KB), los_sched.c (19KB)模块，并搭建测试集，完成编译检验 |
Vexilon 是中国科学技术大学 2026 春季学期 OSH-2026 课程项目小组。项目聚焦于：
- 在 LiteOS-M 现有 C 语言内核和往年小组改写的基础上，继续进行 Rust 深入式重构；
- 在内核与用户层之间引入 IronClaw 中间层，构建安全、可扩展的双向调用接口；
随着 IoT 设备从“能运行”转向“可长期安全运行”，传统 C 语言内核在内存安全与并发安全方面的系统性风险逐渐放大：
- 裸指针与手动内存管理容易引发 UAF、越界写、空指针解引用、双重释放等问题；
- 并发安全依赖人工规范，在多任务/多核场景下易出现竞态条件；
- 资源受限设备上难以依赖重型运行时检测手段进行兜底。
Rust 在 no_std 场景的成熟度提高，以及操作系统领域（Linux、Android 等）对 Rust 的持续引入，使得“对高风险模块优先 Rust 化”成为现实可行路线。
在此基础上，本项目进一步探索 IronClaw 的能力边界：通过安全接口桥接用户层与内核层，支持后续 AI 驱动的系统实验自动化与策略评估。
本项目重点关注以下三类问题：
- 内存安全问题：内核堆管理、任务控制块、链表/队列等路径存在潜在越界与悬挂指针风险；
- 并发安全问题：锁使用正确性依赖人工经验，难以在编译期发现竞争访问错误；
- 调用安全与隔离问题：用户层到内核层接口缺乏统一能力边界与强类型约束。
- 在保证 LiteOS-M 轻量与实时性特征的前提下，提升内核关键路径的内存安全与并发安全；
- 完成可运行的核心功能链路：任务管理 + 调度 + 至少 1 个 IPC 场景；
- 建立用户层到内核层、内核层到用户层的统一接口原型。
- Rust 改写后的 LiteOS-M 核心模块代码（分阶段提交）；
- IronClaw-LiteOS-M 接口层设计与原型实现（含双向调用接口）；
- 实验与验证报告：功能正确性、性能影响、安全性收益；
- 文档化迁移方法：模块优先级、接口策略、测试流程、风险清单。
- 语言与运行环境：Rust（no_std + alloc）+ C（混合内核）；
- 交叉编译与构建：cargo + LiteOS-M 原有构建链路；
- 交互与绑定：FFI/bindgen、repr(C) 数据结构对齐；
- 验证环境：单元测试 + QEMU 仿真 + 开发板真机测试。
flowchart TD
A[用户应用] --> B[IronClaw 接口层<br/>系统调用封装、权限校验、参数检查]
B --> C[Rust 改写内核模块<br/>Task / Sched / IPC / Memory]
C --> D[LiteOS-M 其余模块与硬件抽象层]
- 用户层 -> 内核层：任务管理、调度控制、IPC、内存管理接口；
- 内核层 -> 用户层：事件通知、回调注册与触发。
基于调研与可行性分析，本项目把“Rust-LiteOS-M 核心链路验证”作为第一目标，而不是多协议无线展示。开发板选择优先级如下：
| 开发板/芯片 | 无线能力 | 资源规模 | LiteOS-M / OpenHarmony 适配 | Rust/FFI 适配风险 | 结论 |
|---|---|---|---|---|---|
| Hi3861 / HiSpark / BearPi-HM Nano | WiFi | 160MHz, 352KB SRAM, 2MB Flash | 高 | 中 | 主线首选 |
| RK2206 | WiFi/AP + NFC | 中 | 中高 | 中偏高 | 备选 |
| ESP32-C3 | WiFi + BLE | 160MHz, 400KB SRAM, 4MB Flash | 中 | 中 | Rust 验证备选 |
| ESP32-S3 | WiFi + BLE | 资源更大 | 中 | 中偏高 | 展示备选 |
| BL602 / W800 等 | WiFi + BLE | 较紧张 | 中低 | 高 | 不建议主线 |
当前阶段最终目标采用 Hi3861V100 单板完成核心验收项：
- LiteOS-M 真机启动与任务运行；
- C/Rust FFI 双向调用；
- IronClaw-Lite 命令校验（能力+参数）；
- LiteOS-M Queue IPC 联调；
- 小规模内存压力测试与稳定性观察；
- WiFi 文本命令输入 + UART 保底调试输出。
推荐方案的核心理由：
- 路径最短：减少板级移植与驱动不确定性；
- 生态匹配：与 LiteOS-M/OpenHarmony 示例和资料高度贴合；
- 风险可控：把时间集中在“任务/IPC/内存 + 接口安全链路”本体。
为确保课程周期内可交付，本阶段不把 BLE、OLED、温湿度传感器、蜂鸣器作为主线依赖：
- 蓝牙与 WiFi 并行会引入协议栈共存、回调线程与内存池竞争问题；
- 复杂外设会把重点从“内核能力验证”转移到驱动联调；
- Hi3861 资源有限，更适合轻量文本协议（TCP/UDP）而非重型 HTTP + JSON；
- 先完成 WiFi + UART 闭环，再决定是否扩展多外设展示。
EcoPet 在本项目中是“系统验证场景”，不是“外设堆料项目”。
目标是用一个可控 Demo 串起以下链路：
- LiteOS-M 启动与任务调度；
- C/Rust FFI 接口调用；
- IronClaw-Lite 命令解析、权限检查、参数检查；
- Queue 作为 IPC 通道解耦输入与状态更新；
- Rust 状态机更新宠物状态并输出遥测。
建议链路：
UART/WiFi 文本命令 -> IronClaw-Lite 校验 -> LOS_QueueWrite -> PetStateTask -> Rust 状态机 -> UART/WiFi 输出
- LiteOS-M + UART 跑通：上电日志 + 三任务创建（NetRxTask/PetStateTask/TelemetryTask）。
- C 调 Rust 跑通：最小验证
FEED 10，返回标准错误码与成功日志。 - Queue 跑通：校验通过命令入队，由状态任务独占消费。
- WiFi 输入：PC/手机发送
STATUS/FEED/PLAY/SLEEP，开发板返回状态。
说明：建议先用 TCP/UDP 文本命令，不在首阶段引入 HTTP 服务与 JSON 解析。
任务分工遵循“单写者模型”，降低并发风险：
NetRxTask：接收 UART/WiFi 文本命令，调用ic_parse_command，通过后写入队列；PetStateTask：从队列读取命令，调用ic_pet_apply_command，作为唯一状态写入者；TelemetryTask：周期调用ic_pet_get_state只读快照并上报。
该划分可避免“输入任务直接改状态”导致的共享写冲突。
建议保持轻量文本协议，便于资源受限平台调试：
STATUSFEED n（n建议范围 1~100）PLAY n（n建议范围 1~100）SLEEPSTRESS_MEM count block_size（示例：STRESS_MEM 100 64）
参数边界建议：
count <= 200block_size <= 128
约束目的：让压力测试验证“接口正确性与稳定性”，而不是把问题退化为“资源耗尽”。
推荐基础压测命令：STRESS_MEM 100 64
通过标准建议至少满足：
- 返回
ECO_OK； - 无 hard fault；
TelemetryTask持续输出；- 压测后
STATUS仍正常； - 压测后
FEED 10仍可更新状态。
为保证主线闭环，当前阶段不作为验收条件的内容包括：
- 完整 IronClaw runtime 与 WASM 动态加载；
- 复杂 HTTP 页面与大 JSON 解析；
- 大规模内存压测（高次数/大块）；
- 多传感器 + OLED + 蜂鸣器同时集成；
- BLE 手机控制链路。
- 2024 届成果已完成 mm/los_memory.c 的 Rust 改写（动态内存管理）。
详情见调研报告，待改写模块按优先级分为三类：
详细的改写原因、难点分析与适配性说明见调研报告与可行性报告。
- 完成 los_sortlink.c 改写；
- 跑通 FFI 与模块级测试闭环；
- 沉淀统一编码模板与接口命名规范。
- 联合改写 los_task.c + los_sched.c；
- 打通任务创建、阻塞/唤醒、优先级调度链路；
- 建立关键路径性能基线。
- 选择 1~2 个 IPC 模块完成改写与联调；
- 验证任务间通信与同步语义正确性。
- 对接 Tick/定时器/初始化流程；
- 完成 IronClaw 双向接口原型；
- 形成完整报告与演示材料。
- 单元测试：验证模块内部数据结构与边界行为；
- FFI 交互测试：验证 C/Rust 参数传递与 ABI 一致性；
- QEMU 仿真：验证任务调度、IPC、定时器等核心场景；
- 真机测试：验证实时性指标、稳定性与资源占用；
- 安全回归：重点检查空指针、越界、竞争访问路径。
- 渐进式 Rust 化路线：从可独立模块切入，降低重构风险；
- 类型安全内核原语：提升关键路径可审计性与可靠性；
- IronClaw 统一交互层：探索 AI Agent 与 RTOS 的安全融合方式；
- 工程方法论沉淀：为后续课程/社区项目提供可复用模板。
- no_std 适配复杂：优先建立最小可运行模板，逐步扩展能力；
- C/Rust 混合编译复杂：以小模块先行验证链接链路；
- 实时性回退风险：引入阶段性基准测试与回归阈值；
- 模块耦合导致联调困难：采用“接口先对齐、功能后替换”策略。
以下为建议的后续目录组织方式，便于代码与文档协同维护：
- docs/：调研报告、可行性报告、阶段总结、实验记录；
- src/ 或 rust_kernel/：Rust 改写模块代码；
- bridge/：IronClaw-LiteOS-M 接口层与绑定代码；
- tests/：单元测试、集成测试、仿真脚本；
- tools/：构建与分析脚本。
- LiteOS-M（Gitee）：https://gitee.com/openharmony/kernel_liteos_m
- IronClaw（GitHub）：https://github.com/nearai/ironclaw
- Tock OS（GitHub）：https://github.com/tock/tock
- Hubris（GitHub）：https://github.com/oxidecomputer/hubris
- Microsoft: We need a safer systems programming language: https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-safer-systems-programming-language
- NSA: Software Memory Safety: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF