第一阶段总结

1年前开始学习rust，初衷是了解一门操作系统级别的开发语言(深入了解，作为工作语言那种)。并为此写了系列的微信公众号文章《拥抱未来语言Rust》并在社区取得了不错的反响，感兴趣的可以微信公众号搜索“三角兽”，欢迎关注。
rust作为一门系统级语言，拥有高性能的同时还具有高安全性，基于RAII风格自动资源管理，避免了很多内存安全问题(这也是吸引我学习的主要原因)。本次比赛是我第一次参加的系统级比赛，通过比赛，夯实了对rust语言的理解，包括：所有权，作用域，生命周期，智能指针等。非常有意义，在此感谢主办方！

第二阶段总结

一直以来对OS非常感兴趣，本次通过身临其境的“代码调试”，熟悉了整个项目架构，并对OS有了进一步的深刻认识。在调试过程中不仅熟悉了OS，还对Rust语言有了更深入的认识。第二阶段的操作系统实现基于RISC-V指令集，之前没有了解过RISC-V，因此看汇编语言会有些头痛，但结合RISC-V手册加上AI的辅助，理解这些汇编代码完全没有问题。
通过第二阶段的学习，破除了一直以来对操作系统底层实现机制的迷雾，那层隔阂在应用开发人员心底的对操作系统的朦胧自此打破，世界上没有彩蛋，只有认识盲区，破除这些盲区，就是扩大自己的认知，增加自己的技术自信。后面打算写系列的博客来总结、分享操作系统，影响更多的人来学习操作系统。

下面是第二阶段各个实验的总结，重要的知识点我都画成了流程图，希望帮到需要的人。

lab1

这是第一个实验，整体难度不大，通过print打印信息调试，一天过关。

lab2

地址空间映射这一章知识密度较高，反复看了几遍才基本弄懂，调试代码陆陆续续调试了3天。(还是太菜，菜就多练！)

简单总结下本章：在开启分页SV39分页之前，OS和都是直接访问物理地址，这给系统带来很多潜在的安全隐患，例如地址空间未隔离等。开启分页模式后，OS和用户代码中就都是虚拟地址了，需要通过页表和MMU进行转换，并且页表上的属性区分出了U和S，进行了权限和空间的隔离，分别在特权级和地址空间上保证了OS内核的安全，同时也保证了用户程序之间相互隔离，彼此空间不会重叠。(虚拟空间可以重叠，但通过页表映射后通常是隔离的，有种特殊情况是通过映射到相同的物理也实现内存共享)

另外为了OS在开启分页后能平滑的访问，对于OS采用的是恒等映射(虚拟页号=物理页帧)。而对于用户程序通常采用Framed映射，通过栈式页帧分配器分配页帧并和虚拟页号建立映射关系，动态生成页表及页表项，实现物理页帧的按需分配。

另外一个比较好的抽象是地址空间MemorySet，它作为任务的一部分，管理着页表及和逻辑区。在实现采用了RAIL机制，加上rust的所有权及drop trait自动实现页表项的释放。

lab3

sys_spawn第一版实现测试通过，但是到实验4发现实现有问题，然后修改为exec+fork的方式完成。

lab4

文件系统章节是我花时间最多的一个章节，时间主要花在了对文件系统的理解上，看源码也费了些时间。将细节通过在线文档整理如下图所示：

lab5

死锁检测可以基于银行家算法实现，参考Wiki

总结

一直以来对OS非常感兴趣，通过本次的“代码调试”，熟悉了整个项目架构，并对OS有了进一步的深刻认识。在调试过程中不仅熟悉了OS，还对Rust语言有了更深入的认识。
本次实现的功能是打印任务信息：系统调用及调用次数，运行时间。
整体思路：在syscall入口处调用set_task_info方法。每调用一次系统调用，更新一次syscall_times和time。
踩的坑：需要注意Rust结构体与C结构体的区别，Rust编译器会对Rust中的字段进行重排序，以达到优化存储的目的。在OS中的结构体和user中的结构体字段要保持一致，否则会蛋疼:(
另外附图一张，表示我曾用心学习:)

第一题

应用分别出现：

• PageFault in application, bad addr = 0x0 bad instruction = 0x804003a4 , kernel killed it.
• IllegalInstruction in application, kernel killed it.
  使用的sbi版本是：RustSBI version 0.3.0-alpha.2

第二题

1.刚进入__restore时，a0代表kernel stack pointer ， restore的两种使用场景：a.trap 恢复 b.创建新任务

2.处理了sstatus sepc sscratch。sstatus用于指定返回的特权级(SPP字段)；sepc用于指定返回后执行哪条指令；sscratch存储着用户栈地址，U态程序要执行必须正确找到U态的栈地址。

3.application不会使用x4;x2已经被交换到了sscratch代表着用户栈指针

4.sp指向user stack , sscratch 指向kernel stack

5.__restore总状态切换在csrw sstatus,t0这行指令，sstatus中的SPP字段记录了陷入前的特权级，csrw sstatus,t0执行后，恢复到用户特权级。最后的指令sret ，指令返回用户程序，原因是该指令会从sepc中读取指令地址，并赋予pc寄存器，而U态的栈等已恢复好，sret临门一脚，步入U世界。

6.指令之前sp -> user stack , sscratch -> kernel stack ;指令后sp -> kernel stack, sscratch -> user stack。指令进入内核运行。并且用sscratch保存着U态的栈地址，从内核态返回即可用sscratch恢复用户态栈指针。

7. csrrw sp,sccratch, sp是程序从U态进入S态的关键指令，sp指向内核栈。

荣誉准则

1. 在完成本次实验的过程（含此前学习的过程）中，我曾分别与 以下各位 就（与本次实验相关的）以下方面做过交流，还在代码中对应的位置以注释形式记录了具体的交流对象及内容：
   无

2. 此外，我也参考了 以下资料 ，还在代码中对应的位置以注释形式记录了具体的参考来源及内容：

   我的参考资料：rCore-Tutorial-Book-v3

3. 我独立完成了本次实验除以上方面之外的所有工作，包括代码与文档。 我清楚地知道，从以上方面获得的信息在一定程度上降低了实验难度，可能会影响起评分。

4. 我从未使用过他人的代码，不管是原封不动地复制，还是经过了某些等价转换。 我未曾也不会向他人（含此后各届同学）复制或公开我的实验代码，我有义务妥善保管好它们。 我提交至本实验的评测系统的代码，均无意于破坏或妨碍任何计算机系统的正常运转。 我清楚地知道，以上情况均为本课程纪律所禁止，若违反，对应的实验成绩将按“-100”分计。

总结

地址空间映射这一章知识密度较高，反复看了几遍才基本弄懂，调试代码陆陆续续调试了3天。(还是太菜，菜就多练！)
简单总结下本章：在开启分页SV39分页之前，OS和都是直接访问物理地址，这给系统带来很多潜在的安全隐患，例如地址空间未隔离等。开启分页模式后，OS和用户代码中就都是虚拟地址了，需要通过页表和MMU进行转换，并且页表上的属性区分出了U和S，进行了权限和空间的隔离，分别在特权级和地址空间上保证了OS内核的安全，同时也保证了用户程序之间相互隔离，彼此空间不会重叠。(虚拟空间可以重叠，但通过页表映射后通常是隔离的，有种特殊情况是通过映射到相同的物理也实现内存共享)

另外为了OS在开启分页后能平滑的访问，对于OS采用的是恒等映射(虚拟页号=物理页帧)。而对于用户程序通常采用Framed映射，通过栈式页帧分配器分配页帧并和虚拟页号建立映射关系，动态生成页表及页表项，实现物理页帧的按需分配。

另外一个比较好的抽象是地址空间MemorySet，它作为任务的一部分，管理着页表及和逻辑区。在实现采用了RAIL机制，加上rust的所有权及drop trait自动实现页表项的释放。

第一题

最低的位则是标志位，它们的含义如下：
仅当 V(Valid) 位为 1 时，页表项才是合法的；
R/W/X 分别控制索引到这个页表项的对应虚拟页面是否允许读/写/取指；
U 控制索引到这个页表项的对应虚拟页面是否在 CPU 处于 U 特权级的情况下是否被允许访问；
G 全局页表项。这意味着即使是在上下文切换（例如，进程切换）之后，该页表项也不会被冲洗（flushed）或失效。简而言之，G位用于指示页表项在地址空间的多个上下文中保持有效。
A(Accessed) 记录自从页表项上的这一位被清零之后，页表项的对应虚拟页面是否被访问过；
D(Dirty) 则记录自从页表项上的这一位被清零之后，页表项的对应虚拟页表是否被修改过。

第二题

荣誉准则

1. 在完成本次实验的过程（含此前学习的过程）中，我曾分别与 以下各位 就（与本次实验相关的）以下方面做过交流，还在代码中对应的位置以注释形式记录了具体的交流对象及内容：
   无

2. 此外，我也参考了 以下资料 ，还在代码中对应的位置以注释形式记录了具体的参考来源及内容：

   我的参考资料：rCore-Tutorial-Book-v3

3. 我独立完成了本次实验除以上方面之外的所有工作，包括代码与文档。 我清楚地知道，从以上方面获得的信息在一定程度上降低了实验难度，可能会影响起评分。

4. 我从未使用过他人的代码，不管是原封不动地复制，还是经过了某些等价转换。 我未曾也不会向他人（含此后各届同学）复制或公开我的实验代码，我有义务妥善保管好它们。 我提交至本实验的评测系统的代码，均无意于破坏或妨碍任何计算机系统的正常运转。 我清楚地知道，以上情况均为本课程纪律所禁止，若违反，对应的实验成绩将按“-100”分计。

实验总结

文件系统章节是我花时间最多的一个章节，时间主要花在了对文件系统的理解上，看源码也费了些时间。将细节通过在线文档整理如下图所示：

问答作业

Root Inode 的作用：
文件系统的入口点：在类 Unix 文件系统中，root inode 是文件系统层次结构的根，即 / 目录。它是访问文件系统其余部分的起始点。
存储目录信息：root inode 存储了根目录下的文件和子目录的元数据，例如它们的名称、inode 编号、文件类型（文件或目录）等。
维护文件系统结构：root inode 作为文件系统结构的起点，确保了整个文件系统的组织性和可访问性。
权限控制：root inode 还包含了访问权限信息，用于控制对根目录及其下内容的访问。
如果 Root Inode 损坏：
如果 root inode 中的内容损坏，可能会发生以下情况：

无法访问文件系统：由于 root inode 是访问文件系统的入口，如果它损坏，可能会导致整个文件系统无法挂载，用户无法访问任何文件或目录。
数据丢失：虽然文件数据可能仍然存储在磁盘上，但如果 root inode 损坏，系统可能无法定位这些数据，导致数据看似丢失。
文件系统损坏：文件系统的元数据完整性对于文件系统的健康至关重要。root inode 损坏可能导致文件系统元数据不一致，进而导致整个文件系统损坏。
恢复困难：恢复损坏的 root inode 可能非常困难，可能需要专业的数据恢复工具和专业知识。

荣誉准则

1. 在完成本次实验的过程（含此前学习的过程）中，我曾分别与 以下各位 就（与本次实验相关的）以下方面做过交流，还在代码中对应的位置以注释形式记录了具体的交流对象及内容：
   无

2. 此外，我也参考了 以下资料 ，还在代码中对应的位置以注释形式记录了具体的参考来源及内容：

   我的参考资料：rCore-Tutorial-Book-v3

3. 我独立完成了本次实验除以上方面之外的所有工作，包括代码与文档。 我清楚地知道，从以上方面获得的信息在一定程度上降低了实验难度，可能会影响起评分。

4. 我从未使用过他人的代码，不管是原封不动地复制，还是经过了某些等价转换。 我未曾也不会向他人（含此后各届同学）复制或公开我的实验代码，我有义务妥善保管好它们。 我提交至本实验的评测系统的代码，均无意于破坏或妨碍任何计算机系统的正常运转。 我清楚地知道，以上情况均为本课程纪律所禁止，若违反，对应的实验成绩将按“-100”分计。

荣誉准则

1. 在完成本次实验的过程（含此前学习的过程）中，我曾分别与 以下各位 就（与本次实验相关的）以下方面做过交流，还在代码中对应的位置以注释形式记录了具体的交流对象及内容：
   无

2. 此外，我也参考了 以下资料 ，还在代码中对应的位置以注释形式记录了具体的参考来源及内容：

   我的参考资料：rCore-Tutorial-Book-v3

3. 我独立完成了本次实验除以上方面之外的所有工作，包括代码与文档。 我清楚地知道，从以上方面获得的信息在一定程度上降低了实验难度，可能会影响起评分。

4. 我从未使用过他人的代码，不管是原封不动地复制，还是经过了某些等价转换。 我未曾也不会向他人（含此后各届同学）复制或公开我的实验代码，我有义务妥善保管好它们。 我提交至本实验的评测系统的代码，均无意于破坏或妨碍任何计算机系统的正常运转。 我清楚地知道，以上情况均为本课程纪律所禁止，若违反，对应的实验成绩将按“-100”分计。

实验总结

问答作业

荣誉准则

1. 在完成本次实验的过程（含此前学习的过程）中，我曾分别与 以下各位 就（与本次实验相关的）以下方面做过交流，还在代码中对应的位置以注释形式记录了具体的交流对象及内容：
   无

2. 此外，我也参考了 以下资料 ，还在代码中对应的位置以注释形式记录了具体的参考来源及内容：

   我的参考资料：
   rCore-Tutorial-Book-v3
   https://zh.wikipedia.org/wiki/%E9%93%B6%E8%A1%8C%E5%AE%B6%E7%AE%97%E6%B3%95

3. 我独立完成了本次实验除以上方面之外的所有工作，包括代码与文档。 我清楚地知道，从以上方面获得的信息在一定程度上降低了实验难度，可能会影响起评分。

4. 我从未使用过他人的代码，不管是原封不动地复制，还是经过了某些等价转换。 我未曾也不会向他人（含此后各届同学）复制或公开我的实验代码，我有义务妥善保管好它们。 我提交至本实验的评测系统的代码，均无意于破坏或妨碍任何计算机系统的正常运转。 我清楚地知道，以上情况均为本课程纪律所禁止，若违反，对应的实验成绩将按“-100”分计。

阶段一：rust语言学习阶段

作为一名C++程序员，不得不说，rust确实是让人眼前一亮。

所有权机制

rust的所有权是rust语言内存安全的重要特性之一。一块内存（或者说一个值）在任一时刻只能有一个所有者，而其他的地方只能持有这块内存的引用。并且在同一时间内，不能有多个可变借用或同时存在可变和不可变借用。生命周期机制还会在编译时检查内存的生命周期，防止野指针的出现，大大地提高了内存安全性

Option

rust的Option类型（一种枚举类型），有Some和None。这与传统意义上的NULL不同，虽然麻烦了点，但是也保证了安全，并且可读性更强。Option类型是一种显式的枚举类型，要求程序员在定义一个可能为空的值时必须使用Option类型。这种方式使得空值情况成为类型系统的一部分，强制程序员在编译时考虑到值可能不存在的情况。相较之下，Null带来的麻烦反倒会比使用它的便利来说更大一点。

阶段二：rCore OS设计实现阶段

lab1

lab1实现了get_time和get_task_info。粗略地了解了一遍现有的这个框架。

lab2

lab2实现了mmap和mumap，并且重写了lab1的两个实现。由于页表有关的知识之前已经学过了，所以也是光速完成了（自己写了给v2p，虽然后面发现已经有线程的接口可供调用了，难蚌）。

lab3

lab3实现了spawn和stride调度算法（其实压根没实现调度，本来想着先过了拿分，但是截止到这篇博客写下都还没实现）。spawn通常通过fork+exec实现，在这里就各copy一点出来就行了。

lab4

lab4实现了linkat、unlinkat、fstat等。当时写完的时候发现fstat一直无法正确的输出nlink，后来才发现是我inode_id算错了。我一直在找一个只存在于虚空之中（bushi）的inode_id。

lab5

lab5实现了死锁检测（又见到了我们熟悉的dijkstra大神的身影：指银行家算法）。虽然只是粗略地实现了semaphore的检测，但是确实让我更深入的学习了这个死锁检测算法。

其他：

参加这个训练营的时候也才大二，暑假刚看完CSAPP，在看MIT的6.s081，刚看没几节课就听说了这个训练营，不仅很好地巩固了自学时所学到的知识，还学了一门新的，非常优秀的rust语言。非常享受这种解决一个又一个挑战所带来的成就感。

Rustlings

• Rust 的编译器异常严格，尤其在内存安全、生命周期、借用检查等方面。Rustlings 的每个练习都会在编译时给出详细的错误信息，这些错误信息通常带有很强的提示性，帮助理解如何管理内存、如何使用所有权、如何避免数据竞争等
• Rust 的内存管理系统（所有权、借用、生命周期）对比其他语言来说非常独特。特别是在多线程编程中，Rust 提供的无垃圾回收的内存管理方式可以有效避免潜在的并发问题，这使得它非常适合高并发、性能要求高的场景
• 在 Rustlings 中，经常使用到 Result 和 Option 和match,不仅提供了对错误的显式处理，还强制我们处理所有可能的异常情况，避免遗漏潜在的错误分支
• Rustlings有很多智能指针，感觉之前没有接触过类似的东西，各种特性让我理解了很多操作

rCore

• 在 rCore 实验中，我深入理解了操作系统的各个核心部分：进程管理、内存管理、文件系统、系统调用等。每个实验模块都涉及到这些基本概念的实现，通过动手实践，我加深了对操作系统内部机制的理解
• 在内核代码的开发过程中，Rust 强制管理内存的方式迫使我时刻注意内存分配、释放的问题，这大大降低了由于内存问题引发的 BUG 的出现几率
• rCore 的实验涉及到进程调度、线程切换等并发编程内容，这让我更好地理解了操作系统是如何管理和调度多个进程或线程的
• Rust 的多线程编程模型使得并发的实现变得更容易。通过使用 Arc 和 Mutex，我能够有效地管理共享数据，避免了传统的并发编程中容易出现的数据竞争问题
• 在 rCore 的实验过程中，调试是一个非常重要的部分。在操作系统内核层面，调试不像应用程序那样可以直接运行调试工具，而是需要通过打印日志、手动检查内存、模拟调试等方式进行
• rCore 是一个操作系统内核，涉及到硬件编程的部分，比如中断处理、IO 设备控制、虚拟内存等。这些部分让我更加理解了操作系统如何与硬件交互

学了什么

Rustlings

• 学习了rust语言的基本概念
• 了解了所有权,不可变性,生命周期,借用等概念
• 了解RAII的思想(集美u这不是我们c++的RAII吗)

rCore

• 学习了riscv汇编
• 阅读了rCore源码
• 实现了一些简单的系统调用
• 实现了简单的死锁检测
• 被借用检查拷打

收获了什么

• 了解了一些OS的基本概念
• 锻炼了阅读源码的能力
• 练习了debug与编程
• 熟悉了git等工具的使用
• 提高了安全意识

前言

这次加入训练营的前因来自于两位朋友曾断断续续提到了 rCore，以及这个与 rCore 有关的 OS 训练营。

关于 Rust，我曾抱着将信将疑的态度。在社交媒体上关于此的风评给我的感受来讲，就好像万物皆可被该语言重写，这个语言能解决一切编程问题。而包括这种偏见在内等原因，我却没有对 Rust 有太多了解。

而至于 OS，我曾因观看过蒋炎岩的 OS 课程而对 OS 略知一二，但却一拖再拖，因各种原因没有完整的学完全部课程以及做完 labs。

我想，是时候改变这一切了。我最终报名加入了进来。

<–! more –>

PT1. 初次上手 Rust 与 Rustlings

在报名之后，接下来的第一个任务便是完成 Rustlings 全部 110 道题目，以此形成对 Rust 初步的认识。Rust 的基础语法适应起来很快，但是最重要的还是适应 Rust 最核心的 borrow，所有权等一系列与 RAII 相关的设计。虽然碍于 Rustlings 篇幅受限，我没能完整掌握这方面，不过这部分知识还是在 rCore 的实验中补回来了的。

最终，我成功完成了全部的 rustlings 题目，并晋级至重要的下一阶段——rCore。

PT2. rCore 之旅

接下来要完成的，便是相对而言更为重要的 rCore。一路上磕磕绊绊不少，但还是完成了挑战。

首先是 Lab1，Lab1 的任务主要是理清 rCore 原有的代码结构。我在刚看到 rCore 的框架代码的时候，老实讲的确会感觉无从下手。不过，在我花上一段时间了解原本的代码结构，理解调度部分的实现后，就没感觉问题很大了。这中间有个小插曲–由于我一开始看错了题目，我一开始以为 syscall_times 部分记录的是每次 syscall 调用时对应进程运行的时间，但是后来发现其实是每种 syscall 调用的次数。

接下来是 Lab2。因为 Lab2 的框架代码已经提前实现了多种用于内存管理的 struct，我最开始的想法是直接在内存的 PTE 上做文章。但我后续发现，在不对框架原有分配部分不做出大变动的情况下，这种想法似乎并不可行。我好像又有点手足无措，不过思考过后，我最终想到遍历 MemorySet 中全部 MapArea 区间计算并调整区间的方案，总算实现了 map 和 unmap 的 syscall。

Lab2 中重写 sys_get_time 和 sys_task_info 的部分就相对容易些，我实现的方案是按照对应函数所需返回值的大小，对于每个可能包含该变量的虚拟页，反查用户空间对应的物理页，并从内核 0x10000 虚拟页处开始分配虚拟页表然后 map 到对应的物理页。Lab2 原本这部分的实现实际上每次 map 后都不会 unmap 掉， 而是在接下来继续 map 的时候从上一次分配的末尾处 map。但在后面的 Lab 中，由于分配量超出预期，从而会导致其尝试 map 已经在别处分配了的 PTE。到问题发现之后，我添加了 unmap 部分，并使分配都从 0x10000 开始，以此解决了问题。

随后便是 Lab3，相对而言其实还算简单，stride 部分只需要参照题目描述实现。而至于 spawn 部分，可以参照已实现的 fork 与 exec 部分，这样照葫芦画瓢也同样能较为轻松的实现出来。

而接下来的 Lab4，由于项目结构又一次进行了变化，引入了一个新的 easy-fs 库，从而又感到了和刚进行 Lab1 时，没法理解代码结构时的头疼。而在进行 Lab4 的过程中，因为不知为何导致的死锁，我又一次头疼不已，甚至一度想放弃。好在最后因为 Rust RAII 的特性，通过封装一层函数的方式，将某个我并不知情的引用自动 drop 掉，才最终解决了问题。

最后，到了 Lab5，rCore 阶段要结束了。虽然这次我并没有选择将检测死锁的部分独立拆分为单独的 crate，但这部分仍然先在裸机上开发，完成后再移植进内核。由于是直接在裸机上开发，整体调试起来也会方便很多。不过话虽如此，在刚开始的时候，由于我开始进行 Lab5 的时间早于这次线程相关课程的上课时间，且题目没有详尽地描写检测死锁的算法，以及对算法的不熟悉，导致我在这里卡住了很久没有进展。不过最后，我确定了题目给出的算法为 Dijkstra 的银行家算法，在不断的了解这个算法后，最终完成了 Lab5。

至此，一锤定音。

尘埃，已然落定。