偶然有天看到 Rust 中文社区的公众号转发了一个开源 OS 训练营的消息，点进去一看原来是 rCore，早就听过 rCore 这个项目，但一直没来得及学习，自己也对 Rust 在嵌入式开发和内核中的应用很感兴趣，于是转发到群里忽悠了几个朋友一起组团参加

2025春夏季开源操作系统训练营学习总结

2025春夏季我参加了开源操作系统训练营，前三阶段主要是学习了rust语言，并在其两个项目rCore和arceOS中进行实践，下面是我的学习总结。

作为二战选手，上次秋冬训练营止步于第四阶段，之后痛定思痛恶补了一下CSAPP还有RUST圣经，操作系统等这种基础课，还猛猛的参加了Rust训练营，今年磨拳擦掌卷土重来⸜( •ᴗ• )⸝

第一阶段

第一阶段属于是轻车熟路了，通过链表的编写更深刻的理解了Rust的裸指针和智能指针，感慨学无止境，同时也在读张汉东老师的Rust编程之道，后面死灵书等一系列内容都在排队等着学习，对语言的探索多深都不为过。

第二阶段

上一届对于汇编ld文件makefile文件这种东西稀里糊涂，经过过年前后的闭关，把这些知识都补起来了，为了更了解RISCV都汇编指令，通关了傲来训练营的一二三阶段，又自己学习了RISC-V体系结构编程与实践，现在ld文件也看得懂了，makefile也能自己改了，汇编和高级语言之间的调用也知道咋回事了，剩下的就是确定范围和补全逻辑了，有了上一次的经验，这回对从批处理，到进程再到线程的进化有了更深的体会。

第三阶段

第三阶段，上一届前进到写完hashmap因为别的事情就没有继续了，这回有时间慢慢来，一层一层弄清楚调用关系，感受何为模块化操作系统。不过仅是对功能的修改觉得不够尽兴，我也自己拉了一个repo写一个自己的操作系统玩一玩。

阶段一

这一阶段是rustlings刷题，主要是对rust的学习，我接触Rust有一段时间了，Rustlings之前刷过两遍，对我来说还是比较轻松的。

阶段二

这一阶段是rcore的练习，涉及到很多计算机底层软硬件的知识，收获很多。

1. 1～3章

1. 对与程序的内存布局，代码段，数据段，堆，栈，有了更加深刻的认识，学习了高级语言如何与汇编语言进行交互，以及对程序编译链接过程有了的进一步认识
2. 对中断机制有了进一步的了解，学习了中断的处理流程，以及如何在中断处理中保存和恢复寄存器的值
3. 学习了如何在Rust中嵌入汇编语言，以及如何在Rust中调用C语言函数。
4. 学习了CPU硬件特权级的概念，以及如何切换特权级
5. 学习了处理机调度的概念，中断处理流程，以及如何实现基于时间片的的任务切换

2. 第4章

第四章是我花了最多时间的一章，以前对操作系统的内存管理仅仅停留在课本的知识，这一章让我对操作系统的内存管理有了更加深入的了解。

1. 学习SV39的页表结构，对逻辑地址和物理地址的转换有了更加深入的了解，尤其是加深了对逻辑地址，物理地址，页表项，页内偏移量的理解
2. 学习地址空间的切换，以及如何在切换地址空间时保存和恢复寄存器的值，确保操作系统和用户态程序能够正常运行。
3. 学习了操作系统如何管理物理内存，以及如何在物理内存中分配和回收内存。
4. 学习地址空间映射，了解和恒等映射，之前一直在纠结如何保证再开启虚拟内存后操作系统的正确运行。

3. 第5章

第五章是进程管理的章节，主要是学习了进程管理的相关知识，包括进程的创建，退出，等待，以及进程的调度，对进程的概念比较熟悉。

4. 第6章

第六章是文件系统的章节，主要是学习了文件系统的相关知识，包括文件系统的概念，文件系统的实现，以及文件系统的接口。

5. 第7～8章

学习了进程rCore的并发机制，包括信号量，锁，条件变量等概念，以及如何在rCore中实现这些机制。对银行家算法中的资源有了更加深入的了解。

阶段三

第三阶段是对arceos的学习，对组件化OS的设计有了宏观的认识，从unikernel到宏内核再到Hypervisor。相比于rCore，arceos的项目组织更加清晰，代码更加模块化，也更加易于理解。
让我印象最为深刻的是Hypervisor的实现，我之前对Hypervisor的理解是模拟计算机硬件，然后客户机在这些虚拟硬件中执行，对于硬件虚拟化的认识是比较浅的。

总结

这次操作系统训练营是一次非常有收获的经历。

rCore 2025 spring blog

第一阶段

• 这一阶段主要就是了解学习Rust的语法和特性,以及完成所有的rustlings题目, 以及实现一些基础的数据结构和算法, 为之后的项目内容做准备.
• 由于我之前是写Go的并没有接触过Rust，第一阶段以至于后续阶段的编码过程的感觉都非常割裂。

第二阶段

• 第二阶段由多个小lab组成，个人感觉是有一些lab比第三阶段的lab更难，测试用例也更多，每次做都得看看实验指导书才敢下手，也是提前开始做阶段二后面的进度才能赶上来。

第三阶段

• 第三阶段跟着ppt和自己的os理解在慢慢探索，如果没有给出提示我可能要花费两倍的时间才能写完，最后也是瞎摸索完成了阶段三，感觉对操作系统的理解又进了一步的感觉，但还需要持续学习。

前言

本人是大三的计科专业学生，上学期学习了操作系统，颇有兴趣，这学期听说了 opencamp os 训练营，就来深入学习一下。本文是我在完成前三阶段任务后的阶段性总结，主要回顾这一个月的学习历程，并对知识进行整理与查漏补缺。

• rust
  本人在参加训练营之前在 rust 语言上是 0 基础。我花了一周的时间学习了基本语法和特性，并通过了 Rust 编程的阶段。虽然如此，但我对 rust 的掌握还不是很深刻。
  在做 rCore 和 ArceOS 的过程中也会遇到很多语言上的困难，只能走一步看一步，一边完成 os 的编程任务，一边补充对 rust 的理解。
• rCore
  在上学期学习操作系统期间已经了解到有 rCore 这个练习项目，并粗略的看过 《rCore-Tutorial-Book 第三版》的前两章节，只是有了一个大概的了解。这个学期参加了训练营，希望通过学习 rCore 提升工程能力与对 os 的理解。大概花了两周多的时间完成了 rCore-Camp-2025S，期间在内存管理的部分花费了比较多的精力，重点是对多级页表和内核空间与用户空间的理解。在完成了 rCore-Camp-2025S 后，虽不能说对 rCore 了如指掌，但我已掌握了 os 设计的基本思想，当然仍有很多细节上的问题我没有搞清楚的，未来还需要下功夫。
• ArceOS
  这一阶段着重于组件化操作系统的设计与实现，从 Unikernel 模型逐步过渡到宏内核，再进一步到 Hypervisor 架构，核心在于基于组件构造内核。
  Read more »

第二阶段总结

见 2025spring-rust-based-os-comp-stage2-report-loichyan．

主要收获

抢占式内核任务

在前文中，构思了一种单内核栈的思路．但如果需要实现抢占式内核任务，仅凭单个内核栈是无法做到的——当某个内核任务被打断，需要保存完整的上下文，包括整个执行栈．因此，需要在单内核栈的基础上，增加动态分配的内核栈^1．具体而言，

1. 每个任务启动时从内核栈池中领取一个内核栈；
2. 如果该任务正常结束，归还内核栈；
3. 否则，该内核任务被打断（通常是时间片耗尽），将内核栈与上下文一并保存．

这样便能按需使用多内核栈，以最大化利用单核栈带来的优势．

Rust 无栈协程模型

在 Rust 的异步模型中，编译器将每个异步函数转换为一个状态机^2，从而避免了任务挂起时对执行栈的保存（虽然加重了编译器的负担）．因此，Rust 无栈协程模型天然地适用于单内核栈的系统：

• 多内核栈系统中，通过 IRQ^3 (Interrupt ReQuest) 机制等待 I/O 操作时，可以主动放弃执行权从而挂起当前任务，此时需要保存整个执行栈；
• 而在单内核栈系统中，通过 IRQ 机制实现异步 I/O，await I/O 操作时，只需将当前任务加入 Executor 的等待队列即可．

Thread-per-core 模型

在多核环境中，为了保证数据一致性，原子数据结构（如 Arc、Atomic* 等）和同步锁（如 Mutex、RwLock 等）是必不可少的．但除了文件系统读写等任务必须加锁以外，大部分任务都是在单核上处理的，此时对原子计数和同步原语的频繁读写就成了额外的负担．并且，主流异步运行时（如 Tokio、async-std 等）默认要求 Future 多线程安全，这使得编写异步函数没那么“愉快”，也是 Rust 异步体验被广为诟病的一点^4．Thread-per-core 模型^5便因此有了不少拥趸，例如 Glommio^6 是一个适用于 Linux 的 Thread-per-core 框架，它是以 io_uring^7 为基础构建的．

之所以 Tokio 等运行时要求 Future 多线程安全，是因为它们使用了工作窃取的调度算法^8，即在线程 A 创建的任务可能被线程 B “偷走”来减少线程空闲．Linux 的任务调度算法也使用了工作窃取^9．Thread-per-core 和工作窃取模型各有优劣^5：

• Thread-per-core 中，绝大部分数据结构都不必是线程安全的，避免了多线程同步带来的开销，同时也使得编写异步函数更为简便；
• Thread-per-core 中，任务基本上都是在单个 CPU 核心是执行的，减少了执行环境变更导致的高速缓存丢失；
• 工作窃取中，空闲线程从忙碌线程中窃取任务，从而使得各核心之间负载均衡，能最大化利用多核资源；
• 在实际应用场景中，通常不容易彻底区分 CPU 密集型和 I/O 密集型任务，因此工作窃取适用面更广泛．

此外，从 Glommio 的介绍^6中不难看出，它很大程度上依赖于各任务之间的相互协作，即理想情况下，任务需要周期地归还执行权，来使得权重更高的任务优先执行．并且，在 Thread-per-core 模型中，为了充分利用各核心的执行资源，需要将 CPU 密集型和 I/O 密集型任务细致地划分给不同的核心，这无疑给开发维护带来了额外的心智负担．从这个角度来看，Thread-per-core 和工作窃取又分别类似于内核的协作式任务调度^10和抢占式任务调度^11．前两者和后两者的不同之处在于：

• 内核的任务调度算法主要面向于用户任务，它们所需要的资源通常是未知的，并且都希望能独占资源；
• 而同一个应用程序中（内核本身也可以视为一个复杂的应用程序），各任务所需的资源通常有一个预期，因此，在理论上，通过最细致地划分可以让整个应用达到极致的性能．

不过，综合考量各方面因素，还是工作窃取更适用，也更容易实现 :)

总结

以上便是第三阶段的主要收获，接下来需要进一步研究 IRQ 机制与 Rust 异步的集成，以及 io_uring 模型的实现和应用，最终达成对 ArceOS 内核的异步化改造．

目录

1. 第一阶段：Rust编程学习
2. 第二阶段：rCore 操作系统学习
3. 第三阶段：ArceOS 代码阅读与实践
4. 总结与收获

第一阶段：Rust编程学习

感想

第一阶段主要是学习 Rust 语言。Rust 拥有完善的官方文档和丰富的社区资源。
我通过完成 rustlings 练习来熟悉语法和常用特性，遇到不懂的地方就查阅官方手册和社区博客。
这一阶段让我对 Rust 的所有权、借用、生命周期等核心概念有了更深入的理解。

第二阶段：rCore 操作系统学习

感想

第二阶段聚焦于 rCore 操作系统的学习。rCore 项目内容丰富，涵盖了操作系统的各个核心模块。
我花了大约两周时间，逐章阅读并动手实践，过程中遇到不少挑战，但也极大提升了我的系统编程能力。
通过查阅 RISC-V 参考手册和相关资料，逐步理清了内核启动、进程管理、内存管理等知识点。

第三阶段：ArceOS 代码阅读与实践

感想

第三阶段主要是阅读 ArceOS 的源码并尝试参与部分模块的开发。
与 rCore 相比，ArceOS 的架构更加模块化和易于扩展。
虽然刚开始阅读时有些吃力，但通过不断调试和查阅文档，逐渐理解了其设计思路和实现细节。
这一阶段锻炼了我的代码阅读能力和团队协作能力。

总结与收获

通过本次训练营，我不仅系统学习了 Rust 语言和操作系统原理，还提升了独立解决问题和查阅资料的能力。
同时也暴露了自己在算法和底层实现方面的不足，后续会继续加强相关训练。
感谢 rcore-os 社区和各位导师的指导！

参考资料

1. rCore 项目文档
2. Rust 官方文档
3. RISC-V 参考手册

基础阶段 - Rust编程

第一阶段是 Rust 编程，让我印象深刻的是 rustling 中链表的习题，那一刻我深深地怀疑为什么要使用 Rust，在之后的阶段中也多次因为对 Rust 语法的不熟悉而头脑混乱，所以在基础阶段确实要好好利用时间认真地学习 Rust 基础，我现在都还在在过 Rust 圣经…

专业阶段 - OS设计实现

这一阶段就开始对 OS 部分进行学习，二阶段我觉得整个文档都写得非常清晰，整个学习中虽然实验是从第三章开始的，但是或许是因为我之前只是看了操作系统导论，实际上我在第一章节和第二章节的学习上花费了更多的时间，我觉得这个视角就开始切换了，从一开始写应用程序我们进行系统调用和到开发内核的视角，链接脚本，汇编语言，SBI 等等，我觉得理解内核的执行环境也是一个很重要的点

第三章 是对应特权级切换的，学习特权级切换的硬件控制机制，初始化 Trap 处理点 __alltraps() , trap_handler() 实现 Trap 的分发和处理，到 __restroe() 对 Trap 上下文切换的恢复，很有意思的一章

• lab 3: 简单的使用一个数组记录每一个系统调用的次数，比较要注意的是，这里是分时系统，不同程序的系统调用次数要隔离开，一开始我实现的是在每一次加载新的任务的时候对系统调用次数进行重置，但那是在批处理的情况下，批处理是一个一个任务进行的，但是 lab 3 是分时系统，所以存放的位置应该是和任务有关系的.

第四章 是对应地址空间，这里我觉得主要讲解了

1. 在分页机制下，为什么要将 Trap 上下文保存在应用地址空间而不是将其直接放在应用的内核栈，对应理解跳板

2. 然后就是对 __alltraps 和 __restore 下是如何保存和恢复 Tarp 上下文时切换地址地址空间的代码部分的修改

3. 然后就是系统调用后，用户传的地址不要直接解用户地址访问，那是用户空间的虚拟地址

   • lab 4: 主要就是地址空间的转换，对系统调用，如果用户传的是指针的话，都要通过手动查表的方式将地址映射成为内核可以访问的地址, 对 mmap 和 munmap 映射部分，在实现 munmap 过程中，有遇见一个问题，在检查 munmap 是否可以 unmap 的时候，必须要保证每个页都是被 map 过的，并且需要是同一个 MapArea，不然如果分开来，可能会说可能其他逻辑段映射了，但是不是同一个逻辑段，这样是不对的，然后不要忘记在进行 map 的时候要补上 Valid 标志 !

第五章 是进程相关的，内核栈，进程控制块，任务管理器，处理器，进程的调度机制

• lab 5: 内部首先通过 get_app_data_by_name 获得对应 app 的 elf_data, 然后创建对应的 task_control_block, 要注意的是，一开始直接使用 new() 方法，但 new()　只有在创建初始进程的时候才可以，对应的实现从　fork 和 new，exec 方法中可以借鉴，同样要维护对应的父子关系

第六章 文件系统

• lab 6: 这里也是有一个问题，就是引入文件系统后，测试就是之前的测试没有过，在群中找才知道 sprawn 要对对应的标准输出输入和错误的文件描述符进行初始化，所以真的，积极地交流是很重要的，虽然我确实太菜了，很多时候连问题都提不出来,,,不过这也算是一个努力的点吧，都只能一点一点来

第八章 内核态操作系统方法实现锁

• lab 8: 完成死锁检测，主要是对 need 的维护，再检测到安全之后，need 不能直接就恢复，这个恢复need的话，那有可能检测不出来啊，比如说线程1获得1，线程2获得2，然后线程一想要获得2，他去进行检测，然后他不会检测到有问题啊，因为这个时候线程2的need他会以为是0，好他就会认为2会释放啊，然后线程一就会得到这次的sem_down的允许，然后之后线程2想要获得1，如果说线程一的need就恢复了，线程2也会以为线程1是可以释放的，因为此时线程一的need被恢复了，就是原本的0，然后线程2这次的也被允许了，那就死锁了呗
• 然后在对应的 sem_deadlock_2.rs 中，对应的 semaphore.up, 这里的，不能直接就只是 available + 1， 然后对应的 allocation - 1，这样是不可以的，程序会检测到死锁，但实际上没有死锁，在检测的时候，要先看是否是 need，如果有 need 就只是对 need 进行修改，而不是直接改 available 和 allocation，但是理解为什么还比较模糊

项目基础阶段 - 组件化操作系统

在这里我比较印象深刻是文件系统这一部分的实现，一开始我执行 shell 是觉得这部分测试是可以的，在最后提交的时候才发现原来我竟然是使用的标准库的而没有使用 axstd，然后之后再去实现 armf 中的 rename 方法，在同一个文件夹下 rename 的逻辑，而没有 move 的实现逻辑，但是测试的时候依然报错，而且利用输出给我的感觉是整个代码 都没有运行到我的 axfs_ramfs中，实在想不出原因在角落群中才看见 ”rename实现为了启用本地的 axfs_ramfs要在根目录下的 patch 添加本地的 ramfs“，感谢，，，以及被自己蠢哭。。。不过在这个过程中也是算是对整个文件结构有了一定的了解，是一种组件化的感觉

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

rceos
.
├── api
│   ├── arceos_api
│   ├── arceos_posix_api
│   └── axfeat
├── axfs_ramfs
│   ├── Cargo.toml
│   ├── Cargo.toml.orig
│   ├── README.md
│   └── src
├── modules
│   ├── alt_axalloc
│   ├── axalloc
│   ├── axconfig
│   ├── axdisplay
│   ├── axdma
│   ├── axdriver
│   ├── axfs
│   ├── axhal
│   ├── axlog
│   ├── axmm
│   ├── axnet
│   ├── axruntime
│   ├── axsync
│   ├── axtask
│   ├── bump_allocator
│   ├── elf
│   └── riscv_vcpu
├── ulib
│   ├── axlibc
│   └── axstd

总结

恩，其实诚实地说虽然做了实验，但是现在其实还是有一种脑袋空空的感觉，当然我觉得肯定是对这个有更直观的理解了，然后在知识上我觉得自己没有什么要说的，我觉得整个文档写得很好第三阶段石磊老师的课讲得也非常好，而且因为其实本身可能自己的吸收还是没有很系统，确实能力有限，就给一些我自己学习过程的建议吧

首先实验的完成部分很多都是借鉴相关的部分，我觉得在实验上就是要多看相关的代码，然后不断借鉴，也不要怕错，就只有胆大心细

然后就是在看文档知识的时候我比较推荐就是把它拆出来的感觉，然后放在一个类似 excalidraw 或者 draw.io 的看板上，也可以自己写一些批注，我也尝试就是写博客那种但是一整块流下来的感觉怎么说我自己就是看着很累，但是使用化肥然后拆出来我个人感觉是比较顺畅的，也经常在遇见问题之后没有想法的时候，就到处翻翻，或许就能找到答案，而且画图的这种给的笔记压力也比较小一些，但是不得不说在后面内容多之后确实会有点乱，这种情况下我觉得就是需要再梳理的，可能以另外一个形式或者是什么的，但是我觉得这样拆出来之后就算是复习我个人感觉会比较流畅，不会有太大的压力

这是我尝试的两种方法对比，左边是那种拆出来的，右边就是纯文字的博客，我个人是看左边更觉得看得下去一点…

然后这是我的一个粗略的笔记截图，我就是在这个图上找来找去看一下可能有关联的点…

这种方法是我自己学习下来觉得对我帮助比较大的，然后在之后的复习中没有给我太大压力的感觉，当然我认为每个人适合的方式是不同的，这也只是我自己的感受而已，反正客观地看吧

总结

有了第二阶段的基础，第三阶段相对更好理解了，有些第二阶段有点模糊的在第三阶段也更清晰了，第三阶段作业相比第二阶段更简单。

• ex1 print_with_color: 2025.05.06
  先是axhal中修改了，没处理好换行符，导致后面的练习通不过，后换成在ulib里修改
• ex2 hashmap 2025.05.07: 主要参考std中的hashmap
• ex3 bump allocator 2025.05.09: 参考了现有的allocator中的写法,key points:1.四个位置指针，2. allocate时的alignment处理和overlap检查, 3.由于是连续的分配，目前不支持dealloc，足以通过ci了
• ex4 sys_mmap 2025.05.13:找空闲区域，映射找到的区域到新分配的物理内存，加载文件内容到映射好的地址。
• ex5 ramfs_rename 2025.05.14:最刚开始按slides中的完成的是examples/shell,是fatfs, 5.14补做这个ramfs练习
• ex6 simple-hv 2025.05.16: 主要理解指令引发异常后， 会调用_guest_exit, 是通过设置stvec设置trap处理入口地址为_guest_exit , _guest_exit执行完成后就返回到_run_guest的返回地址，执行一下条指令，即vmexit_handler