-
-我其实在去年的时候就对训练营略有耳闻，但是由于在准备算法竞赛，并且对未来研究生的方向还没有一个明确的规划，所以没有参加。而现在，我基本上已经确定了未来要往体系结构和操作系统方向发展，所以第一时间便报名参加了训练营。
-第一阶段学的内容是 Rust。Rust 也是我很喜欢的一门语言，因为他性能高、内存安全、又有良好的包管理器支持，相比于 C、C++，它的语言表达能力更加强大，也有很多好用的语法糖；而相比于 Java、Python 等，它又更为严谨、更贴近硬件。
-经过这一段时间的学习，我越学越觉得 Rust 的很多特性其实是为了给他严格的所有权机制打补丁。最明显的就是生命周期了，还有诸如 unsafe 等。刚好最近同时也在一家公司实习做操作系统内核开发，正在使用 C 语言，因此对这两门语言的风格深有所感：
unsafe。在 Rust 身上可以找到很多为了弥补所有权机制而设计的语法，因此在学习的时候才会觉得 Rust 的语法很复杂。不过这种「语言规定好的规范」对于多人之间的项目合作，特别是开源来说，就是一种优势了。相比于 C 语言项目之间可能存在代码风格相差巨大的情况，Rust 写出来的代码基本上不会有太大的风格差异，这样在参考别人的代码，以及贡献代码的时候就会更为轻松。
- - -
+
+我其实在去年的时候就对训练营略有耳闻，但是由于在准备算法竞赛，并且对未来研究生的方向还没有一个明确的规划，所以没有参加。而现在，我基本上已经确定了未来要往体系结构和操作系统方向发展，所以第一时间便报名参加了训练营。
+第一阶段学的内容是 Rust。Rust 也是我很喜欢的一门语言，因为他性能高、内存安全、又有良好的包管理器支持，相比于 C、C++，它的语言表达能力更加强大，也有很多好用的语法糖；而相比于 Java、Python 等，它又更为严谨、更贴近硬件。
+经过这一段时间的学习，我越学越觉得 Rust 的很多特性其实是为了给他严格的所有权机制打补丁。最明显的就是生命周期了，还有诸如 unsafe 等。刚好最近同时也在一家公司实习做操作系统内核开发，正在使用 C 语言，因此对这两门语言的风格深有所感：
unsafe。在 Rust 身上可以找到很多为了弥补所有权机制而设计的语法，因此在学习的时候才会觉得 Rust 的语法很复杂。不过这种「语言规定好的规范」对于多人之间的项目合作，特别是开源来说，就是一种优势了。相比于 C 语言项目之间可能存在代码风格相差巨大的情况，Rust 写出来的代码基本上不会有太大的风格差异，这样在参考别人的代码，以及贡献代码的时候就会更为轻松。
+ + +因为之前学C++结识的好友群中发了这个训练营的报名链接，想着正好OS还没有学就想着报名参加了:)。参加本次训练营之前只有csapp的计算机体系结构这一相关经验，对于Rust和RISC-V一无所知。编程能力上，主要是C++的服务器开发，做过几个分布式微服务项目，国外的一些公开课lab（CS144/CS106B/CS50等）。
-总体来说第一阶段学习过程还是有点痛苦的，毕竟Rust学习曲线比较陡峭，不过也有许多特性能与C++等语言联系起来，帮助理解。在报名之后就开始翻阅先前训练营的资料开始自学Rust了，总体还是顺利的
-第一阶段主要集中于Rust基础语法的学习，并完成rustlings练习题，其次是进行RISC-V指令集的学习
-Rust学习过程主要参考阅读了《Rust圣经》、《Rust by Example》、和Rust之旅
之后的时间主要是对《Rust圣经》中的进阶部分和基础部分进行阅读笔记并复习，基础部分难点主要集中在所有权和特征这两个知识点上，对于生命周期以及包和模块的讨论并不是特别深入。进阶部分都难哈哈哈哈，迭代器和智能指针还算比较好理解些，对于迭代器加闭包实现的函数式编程每次都让我觉得很强大，Cell和RefCell提供的内部可变性加上智能指针也给程序提供了很大的灵活性的前提下保证了一定的安全性。生命周期的使用也是一大难点了。之后还有unsafe Rust的使用以及宏编程（对比C/C++的难的多但功能性也更强大）
rustlings的基础语法部分不算特别难，不熟练的查一查就能写得出来。难点集中在test和algorithm章节，主要是test后半部分，一些环境变量的设置，以及rust实现数据结构算法所用到的unsafe rust和智能指针的操作。
-之后尝试阅读Learning Rust With Entirely Too Many Linked Lists，和用Rust实现一些算法和数据结构来巩固，多敲一些代码提高熟练度，多查文档。
-这部分知识学习首先是阅读了《计算机组成于设计：RISC-V版》的前两个章节，对RISC-V的基本指令和指令格式有一个了解，以及RISC-V的设计和计算机体系结构的8个伟大思想之间的联系。之前阅读csapp并完成lab实验，有些x86_64的经验，对于一些基本指令和作用的理解还算轻松。难点集中在原子指令上。之后主要阅读了《RISC-V手册》，主要重点是第十章的特权架构，涉及之后rCore的特权级切换操作以及虚拟内存的实现（SV39多级页表）
-学习后可以看出RISC-V指令集的强大和简单，和x86_64不同的理念。六种基本指令格式，等长指令就能搞定一切，精妙的设计（就是有时候脑子转不过来）
-阅读操作系统导论，目前还在虚拟化部分，然后观看导学阶段的OS课录播，补足操作系统的理论知识和概念
- - -因为之前学C++结识的好友群中发了这个训练营的报名链接，想着正好OS还没有学就想着报名参加了:)。参加本次训练营之前只有csapp的计算机体系结构这一相关经验，对于Rust和RISC-V一无所知。编程能力上，主要是C++的服务器开发，做过几个分布式微服务项目，国外的一些公开课lab（CS144/CS106B/CS50等）。
+总体来说第一阶段学习过程还是有点痛苦的，毕竟Rust学习曲线比较陡峭，不过也有许多特性能与C++等语言联系起来，帮助理解。在报名之后就开始翻阅先前训练营的资料开始自学Rust了，总体还是顺利的
+第一阶段主要集中于Rust基础语法的学习，并完成rustlings练习题，其次是进行RISC-V指令集的学习
+Rust学习过程主要参考阅读了《Rust圣经》、《Rust by Example》、和Rust之旅
之后的时间主要是对《Rust圣经》中的进阶部分和基础部分进行阅读笔记并复习，基础部分难点主要集中在所有权和特征这两个知识点上，对于生命周期以及包和模块的讨论并不是特别深入。进阶部分都难哈哈哈哈，迭代器和智能指针还算比较好理解些，对于迭代器加闭包实现的函数式编程每次都让我觉得很强大，Cell和RefCell提供的内部可变性加上智能指针也给程序提供了很大的灵活性的前提下保证了一定的安全性。生命周期的使用也是一大难点了。之后还有unsafe Rust的使用以及宏编程（对比C/C++的难的多但功能性也更强大）
rustlings的基础语法部分不算特别难，不熟练的查一查就能写得出来。难点集中在test和algorithm章节，主要是test后半部分，一些环境变量的设置，以及rust实现数据结构算法所用到的unsafe rust和智能指针的操作。
+之后尝试阅读Learning Rust With Entirely Too Many Linked Lists，和用Rust实现一些算法和数据结构来巩固，多敲一些代码提高熟练度，多查文档。
+这部分知识学习首先是阅读了《计算机组成于设计：RISC-V版》的前两个章节，对RISC-V的基本指令和指令格式有一个了解，以及RISC-V的设计和计算机体系结构的8个伟大思想之间的联系。之前阅读csapp并完成lab实验，有些x86_64的经验，对于一些基本指令和作用的理解还算轻松。难点集中在原子指令上。之后主要阅读了《RISC-V手册》，主要重点是第十章的特权架构，涉及之后rCore的特权级切换操作以及虚拟内存的实现（SV39多级页表）
+学习后可以看出RISC-V指令集的强大和简单，和x86_64不同的理念。六种基本指令格式，等长指令就能搞定一切，精妙的设计（就是有时候脑子转不过来）
+阅读操作系统导论，目前还在虚拟化部分，然后观看导学阶段的OS课录播，补足操作系统的理论知识和概念
+ + +本次主要采用是通过类似于在GNU/LD链接器的方式来完成整个任务。主要的参照依据是csapp中有关链接的相关说明。
目前的实际完成进度在于完成了符号的解析。但是后面的重定包括段重定位以及符号的重定位，目前还没有完成。
目前操作上来说，对于后续任务影响最大的内容在于之前任务的不正确完成，包括但不限于之前任务中埋藏的坑，比如说文件不能正确识别，将 1B 认定成为 一个16进制数而导致对于加载的文件中的align的错误判断，甚至还将用于解释rust内部结构体的自动align用于解释这里所出现的人为导致的align。
-由于其他因素的影响，我在前半段时间其实没有过多的参与到其中来，近几天才加入到课题中。在参加课题之前其实对于libc，musl，甚至是elf文件没有什么过多的了解。简单的了解了下整个过程，本来看了下还想先直接用ld将对应的库链接好之后再放到arceos上读取（这是郝淼同学的实现思路），但是想到在 ld 将各种对象文件链接起来之后，实际上最后在使用的时候还是需要调用链接器 [–dynamic-linker可以指定对应链接器的地址] （当时实际上没想到可以直接实现链接器最后被调用的功能）。后面就按照实现一个链接器的想法继续实验。
-目前主要使用 elf crates 实现了如下效果：
-未来工作可能没有特别大的必要开展，原因如下，在相同情况下，就算最终能够实现了一个能够在arceos上运行的链接器也是没有必要的。
-/// BLUE PRINT
///
/// 1. LOAD APPLICATION
/// 2. SYMBOL RESOLUTION: make sure all symbol has been meet.
/// 3. RELOCATION:
/// [1] RELOCATION SECTION:
/// merges all sections of the same type into a new aggregate section of the same typecombine
/// BC we only need SHT_PROGBITS thus not care about others (copy).
/// [2] RELOCATE SYMBOL REFERENCES IN SECTIONS:
/// Modify references to each symbol in code and data sections so that they point to the correct run-time address
下面的伪代码实际完成了符号加载工作，重定向部分的代码还没有开始实际测试，就算未来有按照这个方法实现的必要，类似郝淼同学重新实现 elf crates 甚至在原先基础上进行修改的行为是必要的，现有的调用过程太长，使用起来不太舒服。
-直接通过 shdr.e_type 实现对于符号的定位，根据CSAPP的说明，使用多个集合对于符号进行处理，实现符号匹配效果
-1 | match ehdr.e_type { |
本次主要采用是通过类似于在GNU/LD链接器的方式来完成整个任务。主要的参照依据是csapp中有关链接的相关说明。
目前的实际完成进度在于完成了符号的解析。但是后面的重定包括段重定位以及符号的重定位，目前还没有完成。
目前操作上来说，对于后续任务影响最大的内容在于之前任务的不正确完成，包括但不限于之前任务中埋藏的坑，比如说文件不能正确识别，将 1B 认定成为 一个16进制数而导致对于加载的文件中的align的错误判断，甚至还将用于解释rust内部结构体的自动align用于解释这里所出现的人为导致的align。
+由于其他因素的影响，我在前半段时间其实没有过多的参与到其中来，近几天才加入到课题中。在参加课题之前其实对于libc，musl，甚至是elf文件没有什么过多的了解。简单的了解了下整个过程，本来看了下还想先直接用ld将对应的库链接好之后再放到arceos上读取（这是郝淼同学的实现思路），但是想到在 ld 将各种对象文件链接起来之后，实际上最后在使用的时候还是需要调用链接器 [–dynamic-linker可以指定对应链接器的地址] （当时实际上没想到可以直接实现链接器最后被调用的功能）。后面就按照实现一个链接器的想法继续实验。
+目前主要使用 elf crates 实现了如下效果：
+未来工作可能没有特别大的必要开展，原因如下，在相同情况下，就算最终能够实现了一个能够在arceos上运行的链接器也是没有必要的。
+/// BLUE PRINT
///
/// 1. LOAD APPLICATION
/// 2. SYMBOL RESOLUTION: make sure all symbol has been meet.
/// 3. RELOCATION:
/// [1] RELOCATION SECTION:
/// merges all sections of the same type into a new aggregate section of the same typecombine
/// BC we only need SHT_PROGBITS thus not care about others (copy).
/// [2] RELOCATE SYMBOL REFERENCES IN SECTIONS:
/// Modify references to each symbol in code and data sections so that they point to the correct run-time address
下面的伪代码实际完成了符号加载工作，重定向部分的代码还没有开始实际测试，就算未来有按照这个方法实现的必要，类似郝淼同学重新实现 elf crates 甚至在原先基础上进行修改的行为是必要的，现有的调用过程太长，使用起来不太舒服。
+直接通过 shdr.e_type 实现对于符号的定位，根据CSAPP的说明，使用多个集合对于符号进行处理，实现符号匹配效果
+1 | match ehdr.e_type { |
此为训练营第三阶段Unikernel项目最终任务的报告
arceos支持Linux原始应用以及支持多应用的实现思路以及验证过程++在思路一的基础上支持思路二
+
思路一
+arceos一起静态编译思路二
+libc接口一致的动态库arceos系统调用函数的地址4本思路
+libc接口一致的库, 和一个动态链接器, 两者和arceos一起静态编译arceos函数每个应用都有一个arceos的TCB, 在其中保存一些关键信息
TCB这部分很简单
+libc一致即可, 目的是让应用感知不到动态库被替换arceos静态链接, 调用系统调用十分方便axlibcglibc或musl-libc++参考 musl-libc 1.2.4 源码
+
对于一个C程序, 其启动流程如下
_start_start, 将当前sp作为参数, 跳转到_start_c_start_c从sp里解析出argc和argv, 跳转到__libc_start_main__libc_start_main进行初始化工作, 完成后跳转到应用的mainmain执行完毕, 回到__libc_start_main__libc_start_main完成收尾工作对于动态编译的程序
+_start, _start_c, main_init, _fini等, 这些往往作为参数交给__libc_start_main进行处理__libc_start_main本身是不包括在程序里的, 也就是说, 需要由我们实现__libc_start_main的实现
hello world程序而言, __libc_start_main的实现十分简单main即可exit即可动态链接器自举
+arceos静态编译, 所以不需要自举对于一个动态链接的应用
+GOT来确定GOT可以确定一个函数名到函数地址的映射GOT, 将函数地址改成正确对应地址dl_runtime_resolve()的地址, 仅当应用调用函数的时候才修改GOT为正确地址本实现里, 使用装入时重定位
+GOT, 改成上文的”实现接口一致的库”的对应函数的地址arceos的设计
libos为了支持多应用, 需要对应用进行内存管理
+TCB里使用一个数组保存应用使用的物理内存arceos的设计
为了支持多应用
+TCB中sv39, 地址空间分为高256G和低256Garceos在完成初始化工作之后, 将自己的运行地址设置在了256G256G即可, 高256G留给内核运行0x10000, 重定位完毕之后, 将数据写入该地址0x10000映射到该内存地址支持页表切换
+main进程运行, 但是此时没有发生调度, 因此需要手动将页表切换成main的页表完善库函数
+__libc_start_main, 初始化和收尾工作必须符合应用期望__libc_start_main实现libc中的相关实现支持运行时重定位
+支持应用创建子线程
+tcb中保存一个pidpid设置为一致, 表示属于同一个进程过程
+riscv版本的Ubuntu, 使用qemu安装并运行musl-libc源码, 编译hello world应用, 使用musl-gcc编译arceos项目文件中, 运行arceos, 成功大概前阵子是和朋友聊天时，有人提到这么一个用Rust写的教学内核，产生兴趣后找来看了才发现训练营的存在。
+我用Rust已经有一段时间了，但多数时候是用来写应用层面的程序，比如web服务。我对操作系统的理解几乎停留在理论，也没有做过系统开发。得知有这么一个难得的机会，那自然不可错过了。
+我的文章中不会着重讲述开发的流程，但会更多地记录一些我自己遇到的比较独特的问题和经历，以及我个人的感想——我自认为我的技术实力是不如许多人的，如果你想找技术上的攻略心得，去看看别人吧。 😋
+不巧的是，在一阶段开始之后不久，我就遇到了一些生活上的琐事。我很快发现自己没有多少时间可以投入到rCore中了。所幸，因为已经有Rust的经验，速通rustlings也只是一晚上的功夫。
+只是，可想而知之后的二阶段恐怕没这么容易了。
+训练营的rCore（Guide）其实已经是rCore Tutorial的再度简化版，但即便如此，第一个任务ch3还是打得我措手不及。
+此前我对操作系统的理解是泛泛的，大致知道操作系统具备哪些东西，最深入的理解也只是本科课程作业中用C编写的调度算法模拟演示。对于一个真正的操作系统，该从哪里开始都不知道，比如说，在no_std的世界中，stdout从哪里来？怎么在屏幕上渲染出日志？（遗憾的是rCore并没有回答这个问题，SBI完成了这部分）
+要一次性消化这么多新东西并不容易，特别是当自己以为已经把Tutorial读得足够清楚了，一打开代码库时依旧觉得无从下手，不得不再次回到Tutorial啃。在这种状况下，我僵持了差不多一个星期才弄清楚ch3究竟应该怎样完成，或者说，代码究竟该写在哪。
+然而，在功能完成后，我的代码出现了一个难以理解的错误：
+1 | Panicked at src/bin/ch3_sleep.rs:16, assertion failed: current_time > 0 |
有很多人遇到了get_time_ms和get_time_us的精度问题，但我很确定我的问题不属于此类——就算我的电脑再怎么快，get_time也绝对不可能是0。
+在反复重写了几个不同的实现方式之后，我开始留意到一个惊愕的事实：“get_time为0”这个错误是否发生，在时间上不均匀。
+有的时候随便改动一两行代码，第一次编译可以通过测试，但第二次之后就会遇上这个错误。
+在探索到深夜时，我发现在get_time加上一个println，就能把这个错误的发生概率降到零。
+Commit, push, CI… Run failed.
+那，把这个println删了试试吧。删除之后，在我的机器上又不能通过测试了，但出于好奇，我还是把这个commit推到了远程。
+这一次，测试通过了。
+这是一个只会在我的机器上出现的错误。
+我使用的是QEMU 8，当然也更换了最新的pre-release RustSBI，但这……我确实没看到有其他人遇到这种问题，也无法理解。
+那么只剩下一种可能了……Apple Silicon。
+虽然已经在ch3得到了教训，我还是没有在第一时间更换Linux虚拟机。我想着，时间已经不多了，同样的问题，或者更诡异的问题出现之后再换虚拟机吧，还是想贪那两秒钟的编译时间。
+幸好，那来自Apple的诅咒之后再没发生过。
+然而ch4的难度直线上升，尤其是对我而言——我对页表一无所知。在ch4感觉到的压力，还有那种面对代码库不知所措的感觉，比ch3还要强烈得多。
+这时我已经萌生了打退堂鼓的想法，ch4无论是知识本身的难度还是任务难度都让我有点招架不住。
+不过，最终还是研究明白了ch4两个函数的实现方式，以及需要为它们补上的其他函数，虽然花的时间远比预期中长。
+ch4完成后，二阶段原定的期限只剩下两天了，我那时还不知道通过的要求已经放宽到了ch5，在周末啃了ch5文档一天之后，我还是决定离开了。
+很遗憾，没能和你们一起走下去。
+……吗？
+在原定的期限一周之后，我发现还有人在冲击着二阶段。
+那么，来画上一个真正的句号吧。
+ch5的难度倒是下降了不少，大概也是因为已经对代码库更加熟悉了。在ch5上花的时间最多的地方竟然是在cherry-pick以前的代码上，花了不少时间手动处理合并冲突，直到能通过编译和通过BASE=1。至于实现两个功能倒是比较轻松愉快，毕竟，现在已经知道代码要加在哪了。
+回过头看，在这个仓库上写的代码，好像真的不多。但是，对于一个未曾了解过操作系统本质的人，可以说是打开了新世界的大门。此刻，操作系统已经变得不再神秘，而rCore Tutorial同样也是值得反复精读的教材。
+最后，也感谢老师们提供的资源以及帮助。
+ + +本次训练营是 Rust 与操作系统的有机结合。我对 Rust 已经足够熟悉，因此侧重操作系统部分的第二阶段更加吸引我。
-从一个裸机程序开始，随着需求的复杂化，我们需要逐步添加各种系统调用的实现，最终完成了一个麻雀虽小五脏俱全的操作系统。
-操作系统和应用一样都是软件程序。区别在于，操作系统需要几乎直接与硬件交互，不像普通应用程序可以使用标准库提供的各种功能，毕竟标准库构建在系统调用上，而系统调用又是由操作系统提供的。
-在操作系统与硬件之间还有一层 SBI (Supervisor Binary Interface)。在后续的编程实验中，我们直接使用编译好的 RustSBI BootLoader 二进制文件。
-RustSBI 规定了 OS 在内存中的位置，那么编译 OS 时需要调整链接器使其生成符合要求的内存布局。
-操作系统最主要的作用就是运行应用程序，而且往往是多于一个应用。一种最直接的想法是把操作系统和多个应用打包在一起，输入计算机后，依次执行每一个应用。
-我们希望当应用出错时，操作系统可以继续执行剩余的其他任务。由此特权级机制被引入。
-一个一个运行应用不够灵活，我们希望能够对多任务进行调度。那么必然就需要能够支持任务切换，即保存/加载上下文。
-调度则主要有两种情况：一是任务主动让出处理器，sys_yield；二是通过时钟中断定时触发任务的切换。
操作系统和应用全都直接访问物理地址通常是低效的。引入虚拟地址机制，让每个应用都拥有逻辑上连续的大量内存，可以使应用的编写更加灵活。
-RISC-V 64 平台采用了 SV39 多级页表机制，通过 satp CSR 来控制是否启用。
此前，所有任务都是操作系统直接管理的。我们很自然的会希望可以由任务来创建子任务，并且可以管理更多物理/虚拟资源。于是引入进程的概念。
-理解进程，最核心的就是相关的系统调用：fork, exec 和 waitpid。
文件可代表很多种不同类型的I/O 资源。狭义的文件系统可以对持久存储设备 (Persistent Storage) I/O 资源进行管理。
-这一节，我们第一次尝试将一组功能从内核中分离出来成为独立的库，交由内核引入使用。
-进程间交换数据大大加强了程序的能力。实现进程间通信的主要方式之一是管道。
-操作系统通过不断切换任务实现并发，因为进程间资源是相对隔离的，这种并发容易实现但开销较大。
-我们想要在进程内，共享资源的情况下实现低开销的并发，这就引入了线程的概念。
-一个进程的多个线程共享资源，但需要能互斥地访问资源，避免数据不一致。为此，我们可以用锁、信号量、条件变量等同步原语。
-rCore 主要目标还是实现一个 Unix-like 的操作系统，编程实验也基本都是实现 Linux 最关键的一些系统调用。
-而 Unix/Linux 本就是与 C 语言一体的。这些 C 风格的系统调用接口，用 Rust 实现起来总是很奇怪，有种削足适履的感觉。
-我在思考，如果抛弃这些 C 风格的接口，从 Rust 出发重新设计接口，或许可以更好地利用 Rust 的众多优秀特性。
- - -本次训练营是 Rust 与操作系统的有机结合。我对 Rust 已经足够熟悉，因此侧重操作系统部分的第二阶段更加吸引我。
+从一个裸机程序开始，随着需求的复杂化，我们需要逐步添加各种系统调用的实现，最终完成了一个麻雀虽小五脏俱全的操作系统。
+操作系统和应用一样都是软件程序。区别在于，操作系统需要几乎直接与硬件交互，不像普通应用程序可以使用标准库提供的各种功能，毕竟标准库构建在系统调用上，而系统调用又是由操作系统提供的。
+在操作系统与硬件之间还有一层 SBI (Supervisor Binary Interface)。在后续的编程实验中，我们直接使用编译好的 RustSBI BootLoader 二进制文件。
+RustSBI 规定了 OS 在内存中的位置，那么编译 OS 时需要调整链接器使其生成符合要求的内存布局。
+操作系统最主要的作用就是运行应用程序，而且往往是多于一个应用。一种最直接的想法是把操作系统和多个应用打包在一起，输入计算机后，依次执行每一个应用。
+我们希望当应用出错时，操作系统可以继续执行剩余的其他任务。由此特权级机制被引入。
+一个一个运行应用不够灵活，我们希望能够对多任务进行调度。那么必然就需要能够支持任务切换，即保存/加载上下文。
+调度则主要有两种情况：一是任务主动让出处理器，sys_yield；二是通过时钟中断定时触发任务的切换。
操作系统和应用全都直接访问物理地址通常是低效的。引入虚拟地址机制，让每个应用都拥有逻辑上连续的大量内存，可以使应用的编写更加灵活。
+RISC-V 64 平台采用了 SV39 多级页表机制，通过 satp CSR 来控制是否启用。
此前，所有任务都是操作系统直接管理的。我们很自然的会希望可以由任务来创建子任务，并且可以管理更多物理/虚拟资源。于是引入进程的概念。
+理解进程，最核心的就是相关的系统调用：fork, exec 和 waitpid。
文件可代表很多种不同类型的I/O 资源。狭义的文件系统可以对持久存储设备 (Persistent Storage) I/O 资源进行管理。
+这一节，我们第一次尝试将一组功能从内核中分离出来成为独立的库，交由内核引入使用。
+进程间交换数据大大加强了程序的能力。实现进程间通信的主要方式之一是管道。
+操作系统通过不断切换任务实现并发，因为进程间资源是相对隔离的，这种并发容易实现但开销较大。
+我们想要在进程内，共享资源的情况下实现低开销的并发，这就引入了线程的概念。
+一个进程的多个线程共享资源，但需要能互斥地访问资源，避免数据不一致。为此，我们可以用锁、信号量、条件变量等同步原语。
+rCore 主要目标还是实现一个 Unix-like 的操作系统，编程实验也基本都是实现 Linux 最关键的一些系统调用。
+而 Unix/Linux 本就是与 C 语言一体的。这些 C 风格的系统调用接口，用 Rust 实现起来总是很奇怪，有种削足适履的感觉。
+我在思考，如果抛弃这些 C 风格的接口，从 Rust 出发重新设计接口，或许可以更好地利用 Rust 的众多优秀特性。
+ + +参加这次训练营的初始目的就是因为曾经多次学习 Rust ，但是因为工作和个人项目使用很少，感觉使用不是很熟练，想借用这次机会加深理解。对 Rust 的兴趣来源于网上将其与 C/C++ 的对比以及称其可以替代 C/C++ 的相关文章，其中让我在意的是它的“零开销抽象”“内存安全性”及 Cargo 。最吸引我的是 Cargo ，相对于 C/C++ 几乎没有包管理，没有集成工具链，偶尔一个开源库的构建让人焦头烂额，Cargo 让我的编程体验有了很大的提升，非常的高效和便捷，rustup 作为工具链管理，非常方便地完成了跨平台编译的工作。相对的，生命周期和借用检查是比较复杂的部分，需要多加学习、实战才能熟练的掌握运用。在本次相关实验中，让我对生命周期、借用检查有了更深的理解，对 unsafe 的相关内容有了新的认识。
-很久就听闻过 RISC-V，诸如阿里的“平头哥”，但是只知道是一套基于精简指令集的开源指令集架构，并不曾深入了解，借本次训练营正好熟悉了相关内容。使用下来发现，RISC-V 的 SBI 提供了很大的便利性，在之前 x86 架构上的 OS 实验未曾体验过相似功能，感觉启动流程似乎没有那么复杂（或者是未使用 grub 等相关 Bootloader）。这次仅使用了 SBI 的少量功能，诸如物理内存探测等其他能力。相较于 x86 , RISC-V 的指令简洁，类似于 pop push 这样的指令都不存在，文档也相对简洁了不少。本次实验中个人对 RISC-V 的相关投入比较少，但非常感兴趣，希望 RISC-V 的生态越来越好，后续能有机会设计一款基于 RISC-V 的 CPU。
-从实验文档的第零章 “实验环境配置” 开始搭建 rCore 实验环境，个人采用 wsl2。在编译 qemu 的过程中发现编译非常慢，一度以为是电脑硬件或操作系统本身导致的原因，后续经过查阅，发现是 wsl2 的问题，在 wsl2 中访问 Windows 分区中的内容会很慢。后来尝试将 qemu 的源码移动到 wsl2 中，编译速度大幅提升。
-从第一章开始 Rust 的实际代码编写，了解了 Rust 除了 std 标准库以外的另一个核心库 core，使用 ![no_mangle] 防止编译器修改函数名称的方法，以及 Rust 的裸机开发能力。第二章讲解了如何实现应用程序以及基于RISC-V的特权级切换完成任务批处理功能，RISC-V 的机器模式(machine mode)、为 Linux、Windows 提供支持的监管者模式(supervisor mode)以及用户模式(user mode)。rCore 的用户程序设计运行在用户模式。从用户模式发起系统调用的操作，特权级寄存器的处理、栈切换、Trap 上下文的保存恢复等相关汇编内容为后续的学习内容的重点。
-第三章实现简单的任务功能，完成任务的加载与切换，使用 RISC-V 提供的时钟中断实现时间片轮转算法来进行任务调度。时钟中断的的开启与中断触发间隔由 RustSBI 提供的相关接口完成设置。
-lab1 的实验内容相对简单，在任务控制块中加入相关字段存储任务首次启动时间及相关任务的系统调用次数，在每次发生中断和系统调用时更新相关系统调用的调用次数。在 sys_task_info 中返回当前时间减去任务首次启动时间及存储的系统调用次数即可。
-第四章开始学习物理内存管理相关内容。使用 Rust 的全局的动态内存分配器的实现 buddy_system_allocator 完成在内核中使用堆空间。
基于 RISC-V 硬件支持的 SV39 多级页表实现地址空间、物理页的分配与回收。开始划分内核地址空间及应用地址空间，实现应用程序不在需要关注应用起始地址及存放位置。相比上一章节的中断和系统调用处理过程添加了跳板页面，来避免在用户模式进入内核模式或内核模式退回用户模式时导致的地址不一致。
lab2 实验中 lab1 实验的相关内容需要重新实现，因为内存分页后在用户态传递进来的参数地址是虚拟地址，内核的访问地址映射和物理地址一致，无法通过虚拟地址对传递进来的参数赋值，所以需要将虚拟地址转换为物理地址，才能完成赋值。
sys_mmap 的实现参考系统中 insert_framed_area 的实现，添加逻辑校验给定的地址中是否包含已经映射的地址即可。sys_munmap 根据 sys_mmap 的实现反推即可实现。
第五章将前面章节中的任务进化为“进程”，讲解了进程的含义、进程的核心数据结构及进程调度。在本章中进程 (Process) 的含义是在操作系统管理下的程序的一次执行过程，是系统进行资源分配的基本单位，进程标识符是进程的id，表示进程的唯一性。内核栈保存着进程运行期间的数据，进程控制块是内核对进程进行管理的单位，等价于一个进程。任务管理器仅负责管理所有进程，处理器管理用于进程调度，维护进程的处理器状态。同时实现了使用 SBI 的 console_getchar 从用户键盘读取输入的用户程序 shell，以及fork 的实现要注意子进程的返回值。
-la3 spawn 的实现调用任务控制块（TaskControlBlock）的 new 方法基于 elf 创建一个新的任务控制块，然后将其添加到当前任务的子线程集合，最后调用 add_task 将其添加到任务调用队列。
-第六章着手文件系统，讲解了文件与文件描述符、标准输入与标准书输出。rCore 对文件系统的设计进行了大量的简化，在进程中结构中添加了文件描述符表，用于语录所有它请求内核打开并可以读写的文件集合。进程通过文件描述符在自身的文件描述符表中招到对应的文件进行操作。rCore 将文件系统独立为 easy-fs 模块，设计感觉比 fat12 简单，分为五层，磁盘块设备接口、块缓存、磁盘数据结构、磁盘块管理器、索引节点，采用 virtio-drivers 库完成了对 qemu 虚拟磁盘的驱动。
-lab4 sys_link 的实现参照 Inode 的 create 方法，创建 DirEntry 指向同一个 inode_id，不同的文件名称。sys_unlinkat 选择使用 modify_disk_inode 方法遍历根目录，在所有的 DirEntry 中查找名称一致的，将其赋值为 empty。ys_stat 主要关注 nlink, 在 DiskInode 中添加 nlink 字段用于记录文件对应的硬链接数量，并且在 DiskInode 初始化、添加硬链接以及删除硬链接时，对应修改其数值。
-第七章开始实现 Linux 中常用的管道符，管道是一种由操作系统提供的进程间通信机制，可通过编程或在shell程序的帮助下轻松地把不同进程的输入和输出对接起来，实现不同进程功能的组合。同时还有基于“事件通知”需求的信号机制，信号是操作系统间通信的一种异步机制，用来提醒某进程一个特定事件已经发生，需要及时处理。与硬件中断进行比较，我们可以把信号描述为软件中断，它们都可以用某种方式屏蔽，还细分为全局屏蔽和局部屏蔽。
-第八章开始为 rCore 支持线程，线程的实现依托于进程，是进程的组成部分，进程可包含 1 – n 个线程，属于同一个进程的线程共享进程的资源。在有了线程后，进程是线程的资源容器，线程成为了程序的基本执行实体。基于前面进程的设计将进程重构，将线程相关数据结构整理转移到线程控制块中，并用进程管理线程控制块，完成相关结构的设计，沿用第三章的任务上下文切换及特权级上下文切换即可。互斥锁、信号量以及条件变量相关机制的引入解决了由多线程引起的线程同步问题，完成了对共享资源的临界区保护，实现的方案有基于原子指令 CAS 及 CAS，以及关闭中断。同时需要考虑实现让权等待防止忙等待占用 CPU 资源。
-lab5 使用银行家算法完成死锁检测，对相关逻辑封装为结构体 DeadlockChecker，在 mutex 和 semaphore 分配时设置可用资源，在申请锁和释放锁时相应的进行资源申请的安全检测和资源的释放。根据提示使用银行家算法完成相关测试，个人感觉有待商榷，实现的有些取巧，后续在整理优化一下。
-本次训练营收获颇丰，对操作系统的原理有了更多的理解，巩固了理论知识，也加强了我对 Rust 的掌握。本次课程未能加入多核相关内容，稍有遗憾。非常感谢训练营的各位老师以及LearningOS的所有贡献者们提供的机会及相关资料。
- - -参加这次训练营的初始目的就是因为曾经多次学习 Rust ，但是因为工作和个人项目使用很少，感觉使用不是很熟练，想借用这次机会加深理解。对 Rust 的兴趣来源于网上将其与 C/C++ 的对比以及称其可以替代 C/C++ 的相关文章，其中让我在意的是它的“零开销抽象”“内存安全性”及 Cargo 。最吸引我的是 Cargo ，相对于 C/C++ 几乎没有包管理，没有集成工具链，偶尔一个开源库的构建让人焦头烂额，Cargo 让我的编程体验有了很大的提升，非常的高效和便捷，rustup 作为工具链管理，非常方便地完成了跨平台编译的工作。相对的，生命周期和借用检查是比较复杂的部分，需要多加学习、实战才能熟练的掌握运用。在本次相关实验中，让我对生命周期、借用检查有了更深的理解，对 unsafe 的相关内容有了新的认识。
+很久就听闻过 RISC-V，诸如阿里的“平头哥”，但是只知道是一套基于精简指令集的开源指令集架构，并不曾深入了解，借本次训练营正好熟悉了相关内容。使用下来发现，RISC-V 的 SBI 提供了很大的便利性，在之前 x86 架构上的 OS 实验未曾体验过相似功能，感觉启动流程似乎没有那么复杂（或者是未使用 grub 等相关 Bootloader）。这次仅使用了 SBI 的少量功能，诸如物理内存探测等其他能力。相较于 x86 , RISC-V 的指令简洁，类似于 pop push 这样的指令都不存在，文档也相对简洁了不少。本次实验中个人对 RISC-V 的相关投入比较少，但非常感兴趣，希望 RISC-V 的生态越来越好，后续能有机会设计一款基于 RISC-V 的 CPU。
+从实验文档的第零章 “实验环境配置” 开始搭建 rCore 实验环境，个人采用 wsl2。在编译 qemu 的过程中发现编译非常慢，一度以为是电脑硬件或操作系统本身导致的原因，后续经过查阅，发现是 wsl2 的问题，在 wsl2 中访问 Windows 分区中的内容会很慢。后来尝试将 qemu 的源码移动到 wsl2 中，编译速度大幅提升。
+从第一章开始 Rust 的实际代码编写，了解了 Rust 除了 std 标准库以外的另一个核心库 core，使用 ![no_mangle] 防止编译器修改函数名称的方法，以及 Rust 的裸机开发能力。第二章讲解了如何实现应用程序以及基于RISC-V的特权级切换完成任务批处理功能，RISC-V 的机器模式(machine mode)、为 Linux、Windows 提供支持的监管者模式(supervisor mode)以及用户模式(user mode)。rCore 的用户程序设计运行在用户模式。从用户模式发起系统调用的操作，特权级寄存器的处理、栈切换、Trap 上下文的保存恢复等相关汇编内容为后续的学习内容的重点。
+第三章实现简单的任务功能，完成任务的加载与切换，使用 RISC-V 提供的时钟中断实现时间片轮转算法来进行任务调度。时钟中断的的开启与中断触发间隔由 RustSBI 提供的相关接口完成设置。
+lab1 的实验内容相对简单，在任务控制块中加入相关字段存储任务首次启动时间及相关任务的系统调用次数，在每次发生中断和系统调用时更新相关系统调用的调用次数。在 sys_task_info 中返回当前时间减去任务首次启动时间及存储的系统调用次数即可。
+第四章开始学习物理内存管理相关内容。使用 Rust 的全局的动态内存分配器的实现 buddy_system_allocator 完成在内核中使用堆空间。
基于 RISC-V 硬件支持的 SV39 多级页表实现地址空间、物理页的分配与回收。开始划分内核地址空间及应用地址空间，实现应用程序不在需要关注应用起始地址及存放位置。相比上一章节的中断和系统调用处理过程添加了跳板页面，来避免在用户模式进入内核模式或内核模式退回用户模式时导致的地址不一致。
lab2 实验中 lab1 实验的相关内容需要重新实现，因为内存分页后在用户态传递进来的参数地址是虚拟地址，内核的访问地址映射和物理地址一致，无法通过虚拟地址对传递进来的参数赋值，所以需要将虚拟地址转换为物理地址，才能完成赋值。
sys_mmap 的实现参考系统中 insert_framed_area 的实现，添加逻辑校验给定的地址中是否包含已经映射的地址即可。sys_munmap 根据 sys_mmap 的实现反推即可实现。
第五章将前面章节中的任务进化为“进程”，讲解了进程的含义、进程的核心数据结构及进程调度。在本章中进程 (Process) 的含义是在操作系统管理下的程序的一次执行过程，是系统进行资源分配的基本单位，进程标识符是进程的id，表示进程的唯一性。内核栈保存着进程运行期间的数据，进程控制块是内核对进程进行管理的单位，等价于一个进程。任务管理器仅负责管理所有进程，处理器管理用于进程调度，维护进程的处理器状态。同时实现了使用 SBI 的 console_getchar 从用户键盘读取输入的用户程序 shell，以及fork 的实现要注意子进程的返回值。
+la3 spawn 的实现调用任务控制块（TaskControlBlock）的 new 方法基于 elf 创建一个新的任务控制块，然后将其添加到当前任务的子线程集合，最后调用 add_task 将其添加到任务调用队列。
+第六章着手文件系统，讲解了文件与文件描述符、标准输入与标准书输出。rCore 对文件系统的设计进行了大量的简化，在进程中结构中添加了文件描述符表，用于语录所有它请求内核打开并可以读写的文件集合。进程通过文件描述符在自身的文件描述符表中招到对应的文件进行操作。rCore 将文件系统独立为 easy-fs 模块，设计感觉比 fat12 简单，分为五层，磁盘块设备接口、块缓存、磁盘数据结构、磁盘块管理器、索引节点，采用 virtio-drivers 库完成了对 qemu 虚拟磁盘的驱动。
+lab4 sys_link 的实现参照 Inode 的 create 方法，创建 DirEntry 指向同一个 inode_id，不同的文件名称。sys_unlinkat 选择使用 modify_disk_inode 方法遍历根目录，在所有的 DirEntry 中查找名称一致的，将其赋值为 empty。ys_stat 主要关注 nlink, 在 DiskInode 中添加 nlink 字段用于记录文件对应的硬链接数量，并且在 DiskInode 初始化、添加硬链接以及删除硬链接时，对应修改其数值。
+第七章开始实现 Linux 中常用的管道符，管道是一种由操作系统提供的进程间通信机制，可通过编程或在shell程序的帮助下轻松地把不同进程的输入和输出对接起来，实现不同进程功能的组合。同时还有基于“事件通知”需求的信号机制，信号是操作系统间通信的一种异步机制，用来提醒某进程一个特定事件已经发生，需要及时处理。与硬件中断进行比较，我们可以把信号描述为软件中断，它们都可以用某种方式屏蔽，还细分为全局屏蔽和局部屏蔽。
+第八章开始为 rCore 支持线程，线程的实现依托于进程，是进程的组成部分，进程可包含 1 – n 个线程，属于同一个进程的线程共享进程的资源。在有了线程后，进程是线程的资源容器，线程成为了程序的基本执行实体。基于前面进程的设计将进程重构，将线程相关数据结构整理转移到线程控制块中，并用进程管理线程控制块，完成相关结构的设计，沿用第三章的任务上下文切换及特权级上下文切换即可。互斥锁、信号量以及条件变量相关机制的引入解决了由多线程引起的线程同步问题，完成了对共享资源的临界区保护，实现的方案有基于原子指令 CAS 及 CAS，以及关闭中断。同时需要考虑实现让权等待防止忙等待占用 CPU 资源。
+lab5 使用银行家算法完成死锁检测，对相关逻辑封装为结构体 DeadlockChecker，在 mutex 和 semaphore 分配时设置可用资源，在申请锁和释放锁时相应的进行资源申请的安全检测和资源的释放。根据提示使用银行家算法完成相关测试，个人感觉有待商榷，实现的有些取巧，后续在整理优化一下。
+本次训练营收获颇丰，对操作系统的原理有了更多的理解，巩固了理论知识，也加强了我对 Rust 的掌握。本次课程未能加入多核相关内容，稍有遗憾。非常感谢训练营的各位老师以及LearningOS的所有贡献者们提供的机会及相关资料。
+ + +我是在某 912 考研群里看到群友发了这次操作系统训练营的宣传图才进来的，事实证明，这是一次非常正确的决定，因为确实挺有趣的，一方面有了个在专业指导下实际上手折腾操作系统的机会，另一方面也确实见识到了挺多东西。
+顺便，我还拉了几个朋友进来一起，可惜他们都比较忙，只是堪堪过了一阶段，在二阶段时正好与他们的考试周和大作业冲突了，于是在二阶段折戟沉沙，只能等下一次训练营时继承这次的存档继续打了（
+操作系统训练营，那自然是以深入了解操作系统为目的的，若是要展示自己在这方面的感悟，那么我想，我可以通过使用伪代码来描述一个简单操作系统所做的事情，以此来反映我在这次训练营中所学到的。
+1 | struct SimpleSYSTEM{ |
如上，这就是在我脑海中操作系统所做的事情，当然，这只是个泛泛而谈的框架，其中每个分支中所进行的操作都包含着值得深入学习的问题，比如 MANAGE_MEMORY 的情况下，我们可能需要进行进程资源的检查，以发现死锁/僵尸进程的情况等，学习这些内容就是参加训练营的目的；
+第一阶段：rust 入门 & rustling: https://github.com/LearningOS/rust-rustlings-2023-autumn-dbydd
+由于我在此之前就自学过 rust，因此第一阶段对于我来说比较轻松，每天抽点时间刷一下 rustling 就能愉快的完成任务了，事实上我在第三天时就已经把 rustlings 刷完了。因此这个阶段实在是没什么好说的…
+第二阶段：rcore 实操训练：https://github.com/LearningOS/2023a-rcore-dbydd
+在我的印象中,rcore 是 ucore 的后辈,两个操作系统都是由清华大学的师生开发出来作为操作系统课的教学工具的;这不正巧,由于下定决心明年要冲 912,我在暑假的时候就先刷了一遍清华的网课,其中就包括了陈老师的操作系统课程,刷完后也瞄了两眼 ucore 的实验部分,由于脑中的知识很新,因此对于实验到还算是得心应手,反而大部分时间都是在与 rust 的语法做斗争.但是不巧的是也遇到了考试周,此外还要准备校内计算机社团的讲课工作与数学建模的备赛,就算是我也感到了分身乏术,进度也就这样被拖慢了下来,直到我写下这段文字时(11.1),也只是将实验推进到了 ch6,好在后续又有通知,这次的二阶段只要完成前三个实验就能进入三阶段,剩下的两个实验在三阶段补齐就行.这样一来或许我也有机会一命通关?整挺好.
+由于是第一个实验，难度并不是很高，只需要给进程附加上一些信息记录，修改很少的代码就能完成。全过程思路如下：首先是要对进程做操作，因此应当去进程相关的代码下做修改。TaskInner 记录的是进程的运行时的程序部分，在这里添加自己的信息不是很合适，于是只剩下了一个可选项：在 TaskControlBlock 中塞东西。
+ch4 主要是关于内存的管理，这部分可以说是一个操作系统的 1/2 个核心部分，在我看来最精简的操作系统，其实就是一个工作在内存上的输入输出机：输入当前的内存，输出特定长度的操作序列至某一片连续内存，并将当前 cpu 的 pc 指向哪个内存的首地址。当那一片连续内存执行完后就回到内核态(也就是继续由操作系统进行一次输出)，如此反复…
+总之，我们只要实现一个虚拟内存的申请和释放就可以了，这部分主要的难点就是可能会一次申请/释放一大片内存，从而需要在多个页表项上进行操作，不过实际实现起来只需要稍加思索就能写出很自然的代码。
+ch5 主要是对进程的管理，自很久以前时分复用的概念被提出开始，任何操作系统都会支持多进程的操作，这甚至不是一件需要特意提及的事情。问题在于：我们要如何设计一个合理的进程系统，并不出差错且用得顺手？
+实验部分有两个，一个是实现 spawn 方法，实验指导文档上给出了标准的 posix_spawn 方法的参考链接。一言以概括之：spawn 方法就是创建子进程用的，那么既然知道了要做什么，怎么做也就非常的显而易见了。
+另一个任务是实现一个简单的进程调度算法：stride 算法，这个算法的想法很自然：给进程加上动态变化的权值，如果一个进程刚刚被执行过，那么它应当不会在短期内被连续执行，除非他的优先值很高，能让他进行连续的执行。
+*未完待续
+