diff --git a/archives/page/4/index.html b/archives/page/4/index.html index c6b202580ea..f529c28df58 100644 --- a/archives/page/4/index.html +++ b/archives/page/4/index.html @@ -184,7 +184,7 @@
在导师的介绍下，了解到开源操作系统训练营这样一个平台。在那之后一直在关注，直到这次秋冬季训练营的开营，我毫不犹豫地选择了报名参与，并与导师一同号召学校的本科生、研究生积极参与。最后，有超过 50 名同学进行了报名，同时通过一阶段的同学有 20 名之多，晋级率大大超过平均水平。
-说回到这次训练营的第二阶段，也就是 rCore 实验的部分。由于前段时间正好做了一下 MIT 的操作系统内核课程 MIT6.s081，并且过了一遍知名操作系统入门教材——《Operating Systems Three Easy Pieces》，因此我在本次实验的理论部分准备还算比较充分，在这方面没有花多少时间，而是主要投身于理解 rCore 的代码架构设计和与此相关的 Rust 语言的一些特性（我在此之前并没有接触过 Rust）。不得不感叹，Rust 语言虽然在写一些数据结构与算法题时非常痛苦，但在用于这种工程项目，尤其是系统软件时，却显得十分优雅，个人认为代码可读性上相比用 C 语言编写的 xv6 来说更高。
-rCore 一共有 5 个实验，基本都是实现系统调用，但是涉及的操作系统模块各不相同，涵盖虚拟内存、进程管理、文件系统和并发控制部分，还算比较全面，题目难度比较适中，给操作系统内核编程入门提供了一个很好的途径。
-尽管 rCore 实验的设计已经很好了，但也仍存在一些不足，最突出的莫过于 测试用例的不全面。很多样例都只检测一个非常表层的信息，而不对其所完成的具体功能进行测试。例如 sys_set_priority 只对返回值进行检测。另一个我的切身体会是，我在完成所有实验后，尝试撰写题解并进行复盘，便把之前写的一些已经“OK”的代码仔细读了一遍，发现从中找出了不少错误，而这些都成功“逃离”了测试样例的“法眼”。当然，编写全面细致的测试具备一定的技术难度与繁琐性，但我还是希望未来能够尽可能的对其进行完善。
最后，虽然 rCore 的学习暂时结束了，但操作系统学习的道路还远未到达终点，也不可能到达终点，期待三、四阶段与 ArceOS 的故事。
+很早之前在翻一个朋友的 GitHub 的时候偶然看见了 rCore-Tutorial-V3 这个项目，今年 9 月便趁着空闲开始学习。因为 rCore-Tutorial-V3 中有不少的测试用例缺失，所以我便试着在 LearningOS 的仓库中找以前训练营的测试用例，然后偶然发现今年的训练营已经开营了，便毫不犹豫参加了。
+因为很早就已经学过 Rust 并且运用在项目当中了，第一阶段算是对 Rust 的复习了，因此花了大改四个小时就完成了。
+前三个实验总体来说还是比较容易的，只有在 Lab3 中需要为进程TCB实现 core::cmp::Ord 遇到了一点麻烦，通过查阅官方文档解决了。在第四个实验的时候就感觉有些不太理解了，因此我查阅了一些操作系统的教材和教学视频才能理解。而第五个实验中的算法，一开始我误认为是银行家算法，然后发现程序没有也无法提供最大需求资源 Max，因此稍稍转变思路成功完成了实验。
经过第二阶段的学习我学习了操作系统的基本概念，并且动手实践编写了一些操作系统功能，我觉得受益良多。
这是我第一次接触完整的操作系统实验，一路走下来可谓是收获颇多。苦于学校教学质量之差，我到处寻找教学资源，例如csdiy，但是从来没有坚持完成过较难的课程。这次rCore也算是弥补了一些遗憾吧。
-在导师的介绍下，了解到开源操作系统训练营这样一个平台。在那之后一直在关注，直到这次秋冬季训练营的开营，我毫不犹豫地选择了报名参与，并与导师一同号召学校的本科生、研究生积极参与。最后，有超过 50 名同学进行了报名，同时通过一阶段的同学有 20 名之多，晋级率大大超过平均水平。
+说回到这次训练营的第二阶段，也就是 rCore 实验的部分。由于前段时间正好做了一下 MIT 的操作系统内核课程 MIT6.s081，并且过了一遍知名操作系统入门教材——《Operating Systems Three Easy Pieces》，因此我在本次实验的理论部分准备还算比较充分，在这方面没有花多少时间，而是主要投身于理解 rCore 的代码架构设计和与此相关的 Rust 语言的一些特性（我在此之前并没有接触过 Rust）。不得不感叹，Rust 语言虽然在写一些数据结构与算法题时非常痛苦，但在用于这种工程项目，尤其是系统软件时，却显得十分优雅，个人认为代码可读性上相比用 C 语言编写的 xv6 来说更高。
+rCore 一共有 5 个实验，基本都是实现系统调用，但是涉及的操作系统模块各不相同，涵盖虚拟内存、进程管理、文件系统和并发控制部分，还算比较全面，题目难度比较适中，给操作系统内核编程入门提供了一个很好的途径。
+尽管 rCore 实验的设计已经很好了，但也仍存在一些不足，最突出的莫过于 测试用例的不全面。很多样例都只检测一个非常表层的信息，而不对其所完成的具体功能进行测试。例如 sys_set_priority 只对返回值进行检测。另一个我的切身体会是，我在完成所有实验后，尝试撰写题解并进行复盘，便把之前写的一些已经“OK”的代码仔细读了一遍，发现从中找出了不少错误，而这些都成功“逃离”了测试样例的“法眼”。当然，编写全面细致的测试具备一定的技术难度与繁琐性，但我还是希望未来能够尽可能的对其进行完善。
最后，虽然 rCore 的学习暂时结束了，但操作系统学习的道路还远未到达终点，也不可能到达终点，期待三、四阶段与 ArceOS 的故事。
最大的感受就是rust的编译器、lint和配套工具链、社区内容太齐全、也太强了，虽然说语法学习有一定难度，但很大程度上被这些优势所弥补了，所以可以说是比较轻松的完成了第一阶段的语法学习。当然对于一些rust编译实现的细节理解确实还有待提升，rust-quiz我在不临时查文档的情况下能正确回答出来的没几个。
+除了rust本身的工具链和社区文档外，给我最大帮助的是两个可以辅助调试rust的工具，rr和fireDBG，堪称rust学习的绝配之作。这两个工具可以可复现地记录rust执行的情况，为一些容易混淆的部分的学习带来了极大的帮助——主要指后面的算法学习，我个人的算法基础较为薄弱，在加上不熟悉的rust语法，没有这两个工具的帮助需要绕不少弯路。
+另外，我很喜欢rust的宏，这是我觉得相当优雅而有趣的工具，只可惜我对于它不是很熟练，但依然感觉到它的上限很高，且与rust本身融合得很融洽。如果有余力的话，我希望能继续深入研究rust的宏。
+最后是对于rust的总体感觉。我感觉在rust身上能看到很多以往学习过的编程语言的影子。基底的c/c++风格、以接口和结构来实现OOP的golang风格、模式匹配和匹配守卫的haskell风格……只能说既视感太强了。rust与其说是完全开创的语言，不如说是在借鉴了大量过往语言的设计基础上的集大成者。这一点到有点像c++，不过没有一些历史包袱，rust的设计可以轻装上阵，抓住精要。
+ + + 一转眼110道题目已经结束，100道语法练习和10道算法题下来让我受益匪浅。对于此前只有一些c语言和python语言基础的我来说，难度比较大，很多概念还是理解不清楚，算法也是临时学的，可谓非常艰难。不过对rust的学习对我的编程思维很有启发，也是我第一次直接接触到并发和所有权的概念。
+ 此前编程单纯考虑能跑就行，但实际上是不够的，作为信息安全专业的人这几年写代码从不考虑安全实在是惭愧，所幸在学生时期接触到了rust,不至于在未来项目出现一些令人痛苦的问题后惊觉对底层知识的忽视。随着学习的深入，越发理解底层知识对编程的重要性，当然这也是我参加2024oscamp的原因。不罗嗦了，那么作为简单的记录，先总结一下吧！
+++ + +：Rust 中有两种字符串类型：
+String和&str。+
String被存储为由字节组成的 vector（Vec<u8>），是一个有效的 UTF-8 序列。String是堆分配的，可增长的，且不是零结尾的。&str是一个总是指向有效 UTF-8 序列的切片（&[u8]），并可用来查看String的内容，就如同&[T]是Vec<T>的全部或部分引用。自定义的错误特征，错误之间很可能会存在上下级关系，例如标准库中的
+std::io::Error和std::error::Error，前者是 IO 相关的错误结构体，后者是一个最最通用的标准错误特征，同时前者实现了后者，因此std::io::Error可以转换为std:error::Error。在存在多个引用时，编译器有时会无法自动推导生命周期，此时就需要我们手动去标注，通过为参数标注合适的生命周期来帮助编译器进行借用检查的分析。
+生命周期标注并不会改变任何引用的实际作用域
+标记的生命周期只是为了取悦编译器，让编译器不要难为我们
+ ——RUST语言圣经
+生命周期注释有一个特别的：‘static 。所有用双引号包括的字符串常量所代表的精确数据类型都是 &’static str ，’static 所表示的生命周期从程序运行开始到程序运行结束。
++
map方法是一个迭代者适配器，它最大的好处不仅在于可以就地实现迭代器中元素的处理，还在于可以捕获环境值。它是惰性的，不产生任何行为，因此我们还需要一个消费者适配器进行收尾：消费者适配器是消费掉迭代器，然后返回一个值。那么迭代器适配器，顾名思义，会返回一个新的迭代器，这是实现链式方法调用的关键：
+v.iter().map().filter()...。+++
filter()的闭包需要用一个引用，并且许多迭代器迭代引用，所以这可能导致混乱的情况，其中闭包的类型是双引用：通常在参数上使用解构来去掉一个+
2
let mut iter = a.iter().filter(|&x| *x > 1);++flat_map()
+map 适配器非常有用，但仅当闭包参数产生值时才使用。 如果它产生一个迭代器，则存在一个额外的间接层。 flat_map() 将自行删除这个额外的层。
+++特性（trait）概念接近于 Java 中的接口（Interface），但两者不完全相同。特性与接口相同的地方在于它们都是一种行为规范，可以用于标识哪些类有哪些方法。
+特性在 Rust 中用 trait 表示：
+格式是:
++++
Rust 同一个类可以实现多个特性，每个 impl 块只能实现一个。
++
+- +
+
Box<T>，可以将值分配到堆上- +
+
Rc<T>，引用计数类型，允许多所有权存在- +
+
Ref<T>和RefMut<T>，允许将借用规则检查从编译期移动到运行期进行.写链表的时候再回忆一下……- +
AsRef 是一个 trait（特质），用于将一个类型转换为另一种类型的引用。
+- +
AsRef 的作用是允许我们以统一的方式处理不同类型之间的转换。通过实现 AsRef trait，我们可以定义一个类型转换函数，该函数将一个类型转换为另一个类型的引用。
+- +
如果我们有一个类型 T，并且希望将其转换为类型 U 的引用，我们可以实现 AsRef
+<U>trait 来完成这个转换。在实现中，我们需要提供一个名为 as_ref 的方法，该方法返回类型 &U。这样，我们就可以使用 as_ref 方法来将 T 转换为 U 的引用。fn num_sq<T: AsMut
+>(arg: &mut T) AsMut< >可变引用。其他同上
+++Rust 宏（Macros）是一种在编译时生成代码的强大工具，它允许你在编写代码时创建自定义语法扩展。
++
2
3
4
5
6
7
// 模式匹配和展开
($arg:expr) => {
// 生成的代码
// 使用 $arg 来代替匹配到的表达式
};
}还有很多没写，笔记记在其他地方了，不过太零散了，有空整理一下。
+
感谢活动主办方提供的宝贵平台和资源！
-希望自己至少能坚持做完二阶段。
-学习资料：
-rustlings 110题 https://github.com/LearningOS/rust-rustlings-2024-spring-zhouyecs（已完成）
-rust语言圣经 https://course.rs
-rust练习实践 https://practice-zh.course.rs/
-rust by example https://doc.rust-lang.org/rust-by-example/
-半小时学习rust https://fasterthanli.me/articles/a-half-hour-to-learn-rust（已完成）
-rust algorithm club https://rust-algo.club/（已完成）
-《rust实战》https://www.amazon.com/Rust-Action-TS-McNamara/dp/1617294551
-（rust资料太多，慢慢学……）
-之前学习过《计算机组成与设计（RISC-V版）》，所以这次只是简单地看了一下PPT for RISC-V特权指令级架构，打算后面有时间学习RISC-V手册：一本开源指令集的指南和Berkeley CS61C: Great Ideas in Computer Architecture (Machine Structures)。
-rustlings 110题 https://github.com/LearningOS/rust-rustlings-2024-spring-zhouyecs
-参考资料
-- The Book - The most comprehensive resource for learning Rust, but a bit theoretical sometimes. You will be using this along with Rustlings!
-- Rust By Example - Learn Rust by solving little exercises! It’s almost like rustlings, but online
做题的时候忘记边做边记录了，所以选了些难点记下来。
-这里和C/C++类似，引用使用 & ，解引用使用 * 。
1 | fn main() { |
Rust中，str和String是两种不同的数据类型，特别容易搞混，str是字符串切片类型，是一个不可变引用，而String是字符串类型，是一个可变的字符串。
1 | fn main() { |
还有更多就没写了，还是得多练练。
- - -感谢活动主办方提供的宝贵平台和资源！
+希望自己至少能坚持做完二阶段。
+学习资料：
+rustlings 110题 https://github.com/LearningOS/rust-rustlings-2024-spring-zhouyecs（已完成）
+rust语言圣经 https://course.rs
+rust练习实践 https://practice-zh.course.rs/
+rust by example https://doc.rust-lang.org/rust-by-example/
+半小时学习rust https://fasterthanli.me/articles/a-half-hour-to-learn-rust（已完成）
+rust algorithm club https://rust-algo.club/（已完成）
+《rust实战》https://www.amazon.com/Rust-Action-TS-McNamara/dp/1617294551
+（rust资料太多，慢慢学……）
+之前学习过《计算机组成与设计（RISC-V版）》，所以这次只是简单地看了一下PPT for RISC-V特权指令级架构，打算后面有时间学习RISC-V手册：一本开源指令集的指南和Berkeley CS61C: Great Ideas in Computer Architecture (Machine Structures)。
+rustlings 110题 https://github.com/LearningOS/rust-rustlings-2024-spring-zhouyecs
+参考资料
+- The Book - The most comprehensive resource for learning Rust, but a bit theoretical sometimes. You will be using this along with Rustlings!
+- Rust By Example - Learn Rust by solving little exercises! It’s almost like rustlings, but online
做题的时候忘记边做边记录了，所以选了些难点记下来。
+这里和C/C++类似，引用使用 & ，解引用使用 * 。
1 | fn main() { |
Rust中，str和String是两种不同的数据类型，特别容易搞混，str是字符串切片类型，是一个不可变引用，而String是字符串类型，是一个可变的字符串。
1 | fn main() { |
还有更多就没写了，还是得多练练。
+ + +目前是大三，未来打算搞系统，目前的话，比较钟意的是OS领域，，因为系统的其他方面，就是并行与分布式这块还行，其他的都过于小众了（bushi），所以当时找到了这个训练营，感觉非常的贴合，就报名了。
+不得不感慨，Rust确实难绷。。我可能也知道了一点Rust为何以安全性著称了，，，，太复杂了，各种约束和检查，让人想死。。
+俗话说得好，C是运行时想跳楼，Rust是编译时想撞墙。。。
+最大的体验是在写数据结构和算法的10道题。。。思路都很简单，然后常常为了语法错误而搞半天。。再次感受到了C的不负责态度。。
+这10道算法题如果用c，大概就是几分钟一道。。但是在这，平均一道都是半小时往上，原因还是在于对其语法的不熟悉。。天天给我报编译错误，我真的麻了，但是熟悉了之后，发现哦原来是这样。
+同时Rust的很多特性确实也让我感觉到了其为何安全（代价就是编码的程序猿会死），不过总得来说，确实是一门非常特别的语言。
+印象深刻的几个点：
+首先是在牵扯build.rs来构建环境变量的时候，可能是我的环境的问题还是怎么着的，基本可以确定是已经实现了，但是仍然不过，而且貌似评测的有bug，会莫名的通过，然后又不通过，很迷茫。
+然后是算法题的调了老长时间，，，，没有实现Copy特征，，这个问题真的难受，，泛型的使用真的需要再多做练习和学习。后面看了很多别人的博客，，发现把Copy特征提高一级，改成Clone特征的约束，然后再需要传递的地方改成.clone()就过了，，，难绷
+rust的很多的stl和模块化编程也非常的强大，让我看到了强大的解耦合能力和组件化的能力，可以根据编译选项和参数的限制来实现条件编译，在项目实战的时候能带来很多的便利。
+确实是折磨人的好题。。。太折磨了
+因为题目太多了，所以就不放上做题或者说学习过程中的笔记了，只做一个总结。
+最后的话，想对未来的自己push一下，五一马上要到了，不打算出去了，直接图书馆走起，越学越觉得自己菜，越学越觉得需要干的事越多，如果运气好的话（希望，，，但是真渺茫）能在9月解放，大概率是奋斗到12月份了
+目标的话是完成训练营的三个阶段吧。
+ + +事情的起因是在威神群里看到的清华操作系统训练营。一个教你用rust写os的训练营!
+受到了炸药哥、cjj等多位体系结构大佬的影响，且本身自己就有一个想把cs和ai结合起来的梦想。而且了解到开源操作系统研究组研究方向涉及高性能计算，于是果断报名。
+其实我自己也不知道是否对操作系统感冒，对rust的兴趣也不及cpp。我只是喜欢了解计算机科学的底层，加之想找hpc的暑期实习但简历却石沉大海(悲)，且也想扎实自己os基础便来了这里。
+从rust零基础到完成rustlings大概用了两周时间。
+看过rust圣经，rust程序设计语言，做过rust最佳实践的练习，在b站看过网课，还尝试做过两个项目: 用rust实现基本数据结构和用rust实现lua解释器。 真的想说一句:”我xxx!” (请读者自行想象)
+其实依旧是有很多不明白的东西，比如链表的布局其实我是似懂非懂的，只是照搬了它的布局。但为何这样布局当时并没有太清楚。
这样的地方还有很多，就且留到以后慢慢体会。毕竟我是来学os的(嘿嘿)，我始终坚信一点:所有的疑问都会在不断学习的过程中找到答案!
南京大学jyy在他的操作系统课上曾说过一句话:”这个世界需要英雄！”
+我真的真的很喜欢这句话，在这个浮躁的时代，越来越多的人选择卷绩点，水科创，水竞赛，学前后端狠赚一笔()…
+但这样不酷，真的不酷。
我要打下最扎实的计算机科学基础，我要实现真正顶层和底层的结合，我要做ai system!
那么就从认真完成这次操作系统训练营开始吧，第二阶段见!
+我们，一定未来可期!
+ + +自打去年从群友们那里了解到这个训练营之后就一直在关注了，
因为我对操作系统本身就很感兴趣，
加上又是使用 Rust 语言还能有一群小伙伴一起努力何尝不是一个很好的学习机会。
其实去年秋季也有报名过一次，惭愧的是因为各种原因第一阶段都没写完 uwu
对于 Rust 这么个频繁被推荐的语言，难免是有些好奇的，
常常是拿出 《Rust 权威指南》然后翻过前几章与别的语言相差不大的那些部分后打算狠狠一顿学习，
但又是惭愧的是每次品鉴 “生命周期”、“所有权”、“动态分配 Trait” 等几个词语后便急忙把书塞回它该在的地方了。
可恶！怎么这么点字就是看不懂了 ——
于是今年刚报名完春季的训练营后便暗自地赌气：我要一晚上做完第一阶段
-（是的，真的第一天晚上就做完了，鉴定为太能熬夜了）
-除了 Rustlings 外今年还添加了一部分数据结构和算法的内容，包括常见的队列、链表、二叉树和排序等，
而且比较有意思的是因为 Rust 对安全性要求很严苛，找出一种写法不使用 unsafe 也是一种很不错的挑战。
三分时间写七分时间对付编译器那种（雾）
-后续的三周就比较空闲了，我终于找到了一个机会和理由把《Rust 权威指南》看完了，
后来还发现一本《Effective Rust》类似是《Effective Java》或是 C/C++ 版本一样，通过一些案例说明什么写法是好的什么写法不太完美。
期间留下一些小笔记：https://blog.hanbings.io/posts/effective-rust/
总的来说，还是很感谢社区以一个这样的形式提供了一个这么好的学习机会，希望后续的学习还能够坚持下去吧！
那么… 第二阶段见！
自打去年从群友们那里了解到这个训练营之后就一直在关注了，
因为我对操作系统本身就很感兴趣，
加上又是使用 Rust 语言还能有一群小伙伴一起努力何尝不是一个很好的学习机会。
其实去年秋季也有报名过一次，惭愧的是因为各种原因第一阶段都没写完 uwu
对于 Rust 这么个频繁被推荐的语言，难免是有些好奇的，
常常是拿出 《Rust 权威指南》然后翻过前几章与别的语言相差不大的那些部分后打算狠狠一顿学习，
但又是惭愧的是每次品鉴 “生命周期”、“所有权”、“动态分配 Trait” 等几个词语后便急忙把书塞回它该在的地方了。
可恶！怎么这么点字就是看不懂了 ——
于是今年刚报名完春季的训练营后便暗自地赌气：我要一晚上做完第一阶段
+（是的，真的第一天晚上就做完了，鉴定为太能熬夜了）
+除了 Rustlings 外今年还添加了一部分数据结构和算法的内容，包括常见的队列、链表、二叉树和排序等，
而且比较有意思的是因为 Rust 对安全性要求很严苛，找出一种写法不使用 unsafe 也是一种很不错的挑战。
三分时间写七分时间对付编译器那种（雾）
+后续的三周就比较空闲了，我终于找到了一个机会和理由把《Rust 权威指南》看完了，
后来还发现一本《Effective Rust》类似是《Effective Java》或是 C/C++ 版本一样，通过一些案例说明什么写法是好的什么写法不太完美。
期间留下一些小笔记：https://blog.hanbings.io/posts/effective-rust/
总的来说，还是很感谢社区以一个这样的形式提供了一个这么好的学习机会，希望后续的学习还能够坚持下去吧！
那么… 第二阶段见！
#前言
-这并不是我第一次参加了，正如我去年结营仪式上说的，我今年又来了。时光匆匆，下半年就要考研了，目前我依然在猛刷各种竞赛，希望今年能更上一步，有所收获！
-#第一阶段的总结：
由于之前已经参加过了，因此前100题非常轻松的就刷掉了，今年多出来了10题算法题，我一直很喜欢用rust写算法，写起来是真的爽，llvm的优化也很爽，甚至能硬生生的将$n^2$的算法给优化成$n*log(n)$的级别，非常逆天。这10道算法题我只在第八题上卡了一会，疑似是workflow评测的bug？反正我本地跑的单元测试都能通过，最终还是整个重写了一遍才过，非常奇怪。于是顺利的在开始的第二天早上写完了110道题。
战斗，爽！
#前言
+这并不是我第一次参加了，正如我去年结营仪式上说的，我今年又来了。时光匆匆，下半年就要考研了，目前我依然在猛刷各种竞赛，希望今年能更上一步，有所收获！
+#第一阶段的总结：
由于之前已经参加过了，因此前100题非常轻松的就刷掉了，今年多出来了10题算法题，我一直很喜欢用rust写算法，写起来是真的爽，llvm的优化也很爽，甚至能硬生生的将$n^2$的算法给优化成$n*log(n)$的级别，非常逆天。这10道算法题我只在第八题上卡了一会，疑似是workflow评测的bug？反正我本地跑的单元测试都能通过，最终还是整个重写了一遍才过，非常奇怪。于是顺利的在开始的第二天早上写完了110道题。
战斗，爽！
本人是一名大二学生。
-去年三月自学过 rust，使用 rust 写过两三个练习的小程序，所以对 rust 的语法和所有权机制还是比较熟悉的。且从去年年底起，对操作系统相关的知识非常感兴趣，在刷了南京大学 Jyy 老师的课后对操作系统有了大概的概念（虽然并没有做 lab）。
-今年通过同学，了解到这个夏令营。居然是用 rust 来写操作系统！遂叫上两三个队友一起加入了。
-内存安全一直是程序设计中一个难以解决的问题。从原始的 gets 溢出攻击，到最近的 xz 供应链后门事件。多少都利用了内存天生的不安全的特性。
-而 rust 做的事情，是将天生不安全的代码世界，划出一部分 safe 区域。通过在编译器上的工作，保证了程序员只要在 safe 区域内编写代码，程序就可以保证内存安全。
-虽然 safe rust 的表达能力有些时候并不能让人满意，并且在写代码的时候经常和编译器搏斗（）。但在我看来，这实际上是把后续 debug 所需要的精力，提前到了编写代码的时候。
-这个世界上的编程语言一般分为两种：有 gc 的，和没有 gc 的
-在 c/c++中，macllo 或 new 一段内存在 heap 上后，需要程序员自己在不需要这段内存之后，释放这段内存。随后可以让别的代码块使用这段内存。
-这样做的问题在于：
-于是我们有了 gc——
-在 java 这样的语言中，gc（内存回收器）会定期暂停程序的一切行为，回收当前没有被引用的对象所占用的内存。这样的语言还有 go。
-这样就不需要程序员来负责内存的释放了，也就不存在多次释放和不释放的问题了。（虽然循环依赖依旧会导致内存溢出……，但这并没有那么危险）
-但 gc 其实是一个比较“重”的东西，并且会定期“暂停世界”。这在互联网服务（Java/Go）的领域并不关键，但在操作系统/嵌入式这样的领域中，底层并不喜欢 gc 这样的设计。
-rust 利用所有权机制，从另一个角度缓解了内存问题。之所以说是缓解，因为 rust 也没有解决内存溢出的问题。
-rust 中，一个变量可以拥有一段 heap 上的内存的“所有权”。当这个变量结束其【生命周期】后，会自动调用其 drop() 方法
-而变量的“所有权”可以通过函数传递，程序员可以将一个变量的所有权移交给函数内部，然后获得函数移交出来的变量的所有权。
-也可以把变量借给函数，通过 mut 关键字。让函数可以在不获得所有权的前提下，访问变量的值。
-在函数需要修改变量时，也可以把变量可变借用给函数。
-值得一提的是，同一时间可以存在多个借用，或者一个可变借用。这在很大程度上避免了数据竞争
-在多线程程序中，也可以通过 Mutex，Arc 等数据结构，进一步避免并行程序中的数据竞争
-不同于 c/c++，也不同于 java/go。
-rust 在自动内存管理和性能之间，选择了我全都要。
-rust 的 std 遵守着零成本抽象，即意味着同样的功能，使用 rust 和手动编写的代码，性能上是一致的。
-这也能让人更放心的使用 rust 自带的各种数据结构和功能。
-OS 在我看来，是所有软件工程的基础，也是软件工程中的软件工程。
-对硬件： 操作系统只是运行在硬件上的一个程序
-对软件： 操作系统为软件创造了一个虚拟的环境，让软件程序有一种自己正掌握着整个硬件的错觉。并且，操作系统为软件提供了一系列系统调用。
-jyy 老师的课给我的最大的收获，是将一切程序看作一个状态机。
-而操作系统也是一个状态机： 一个管理状态机的状态机。
-从这个视角看待软件世界，能很大程度上避免panic（因为看到繁杂的代码中各种函数，很难不让人头疼和恐慌）
-如果你想体验这种感觉，可以 git clone 一个kernel（？）
-世界上的一切都是魔法
-法师只需要喊出法咒/作出动作，世界就会回应他，在现实中展现神迹。
-程序员只要敲击键盘，电脑就会回应他，屏幕上显示出对应的字母。
-这中间的一切都是被封装好的。就像是魔法一样。
-从普通软件的视角看，他在 systemcall 时，对于该程序来说，下一个瞬间，它所在的世界，就根据其所呼唤的 systemcall 回应了它。
-编写操作系统，其实就是在编制普通软件的世界。
-事实上，操作系统也只是在运用硬件和sbi提供给它的魔法罢了
-以上是在我眼中的 rust 和 操作系统 ，作为一个初学者，难免出现错漏和片面。
-如果读者发现什么需要指正和交流的，欢迎联系我。oveln@outlook。
-以及OvBlog
- - -第三阶段我参加的是向勇老师的项目6：异步操作系统的实现。
-总的来说，6周的项目实训过程中，读了很多代码和文档，做了很多事情，学到了很多的东西。
-在参加训练营之前，我对异步的了解其实也就是局限于说我们IO要异步，让出控制权，仅此而已。
-但是在训练营中，我真正的接触到了何谓真正的异步，以及如何去实现它，受益匪浅。
-同时我也将ArceOS的宏内核版本，将其进行了异步化，使整个内核都使用rust的async和await异步编程实现。
-同时它也是无栈协程的切换方式，且对协程采用多栈复用的抢占。
-在成果上，实现了对ArceOS家族系的Starry的异步化改造，使用async和await等rust提供的异步编程编写内核，已实现核心主体框架；同时对通用操作系统内核下协程的不合理性做调整，实现内核栈池，通过少量堆栈的复用实现对诸如键盘输入等高优先协程处理的抢占机制。
-为后来者留下的东西，首先是代码产出：有充足的代码仓库参考，我将各个小步骤的代码都保存了下来。从原始版本 -> task实现 -> 同步无栈协程与显式执行流 -> 异步无栈协程 -> 多栈复用版本。
-同时留下了若干个人的文档心得：考虑到训练营很多同学对从同步到异步的过程一头雾水，其实我本人最开始也是这样的，我个人认为更好的办法是看别人的代码，看看别人是怎么实现了，跟着别人学，先模仿，再谈能不能超越，因此留下文档如下：
-当然，更多的中间过程结果在项目六，向老师的文档中有所记录，这里不再列出。
-总的来说，第三阶段也算有一定的产出，这么长时间也算没白干，身为一个寄算机人，一切都要落实到代码产出上，光写文档吹牛逼不是一个合格的程序猿。
-对我这个异步小白来说，理解和实现异步，再到利用异步的过程，是比较复杂且困难的，而且所面对的是如此大的一个内核，其藕断丝连的耦合性会对改造造成相当大的麻烦。尤其是我们对整个调度和进程管理的部分进行一次彻底的重构，这种挑战相当之大。
-但是挑战之大，也是挺过来了，在改造整体框架下，大概前前后后推倒重来了十多次，这也是为什么我那么注重保存每一个小步骤的代码。
-总的来说，训练营中我给自己列了一个很高的挑战，也尽力的去完成它了，最后的结果我个人是非常满意的，达到了自己对自己的要求。
- - -本人是一名大二学生。
+去年三月自学过 rust，使用 rust 写过两三个练习的小程序，所以对 rust 的语法和所有权机制还是比较熟悉的。且从去年年底起，对操作系统相关的知识非常感兴趣，在刷了南京大学 Jyy 老师的课后对操作系统有了大概的概念（虽然并没有做 lab）。
+今年通过同学，了解到这个夏令营。居然是用 rust 来写操作系统！遂叫上两三个队友一起加入了。
+内存安全一直是程序设计中一个难以解决的问题。从原始的 gets 溢出攻击，到最近的 xz 供应链后门事件。多少都利用了内存天生的不安全的特性。
+而 rust 做的事情，是将天生不安全的代码世界，划出一部分 safe 区域。通过在编译器上的工作，保证了程序员只要在 safe 区域内编写代码，程序就可以保证内存安全。
+虽然 safe rust 的表达能力有些时候并不能让人满意，并且在写代码的时候经常和编译器搏斗（）。但在我看来，这实际上是把后续 debug 所需要的精力，提前到了编写代码的时候。
+这个世界上的编程语言一般分为两种：有 gc 的，和没有 gc 的
+在 c/c++中，macllo 或 new 一段内存在 heap 上后，需要程序员自己在不需要这段内存之后，释放这段内存。随后可以让别的代码块使用这段内存。
+这样做的问题在于：
+于是我们有了 gc——
+在 java 这样的语言中，gc（内存回收器）会定期暂停程序的一切行为，回收当前没有被引用的对象所占用的内存。这样的语言还有 go。
+这样就不需要程序员来负责内存的释放了，也就不存在多次释放和不释放的问题了。（虽然循环依赖依旧会导致内存溢出……，但这并没有那么危险）
+但 gc 其实是一个比较“重”的东西，并且会定期“暂停世界”。这在互联网服务（Java/Go）的领域并不关键，但在操作系统/嵌入式这样的领域中，底层并不喜欢 gc 这样的设计。
+rust 利用所有权机制，从另一个角度缓解了内存问题。之所以说是缓解，因为 rust 也没有解决内存溢出的问题。
+rust 中，一个变量可以拥有一段 heap 上的内存的“所有权”。当这个变量结束其【生命周期】后，会自动调用其 drop() 方法
+而变量的“所有权”可以通过函数传递，程序员可以将一个变量的所有权移交给函数内部，然后获得函数移交出来的变量的所有权。
+也可以把变量借给函数，通过 mut 关键字。让函数可以在不获得所有权的前提下，访问变量的值。
+在函数需要修改变量时，也可以把变量可变借用给函数。
+值得一提的是，同一时间可以存在多个借用，或者一个可变借用。这在很大程度上避免了数据竞争
+在多线程程序中，也可以通过 Mutex，Arc 等数据结构，进一步避免并行程序中的数据竞争
+不同于 c/c++，也不同于 java/go。
+rust 在自动内存管理和性能之间，选择了我全都要。
+rust 的 std 遵守着零成本抽象，即意味着同样的功能，使用 rust 和手动编写的代码，性能上是一致的。
+这也能让人更放心的使用 rust 自带的各种数据结构和功能。
+OS 在我看来，是所有软件工程的基础，也是软件工程中的软件工程。
+对硬件： 操作系统只是运行在硬件上的一个程序
+对软件： 操作系统为软件创造了一个虚拟的环境，让软件程序有一种自己正掌握着整个硬件的错觉。并且，操作系统为软件提供了一系列系统调用。
+jyy 老师的课给我的最大的收获，是将一切程序看作一个状态机。
+而操作系统也是一个状态机： 一个管理状态机的状态机。
+从这个视角看待软件世界，能很大程度上避免panic（因为看到繁杂的代码中各种函数，很难不让人头疼和恐慌）
+如果你想体验这种感觉，可以 git clone 一个kernel（？）
+世界上的一切都是魔法
+法师只需要喊出法咒/作出动作，世界就会回应他，在现实中展现神迹。
+程序员只要敲击键盘，电脑就会回应他，屏幕上显示出对应的字母。
+这中间的一切都是被封装好的。就像是魔法一样。
+从普通软件的视角看，他在 systemcall 时，对于该程序来说，下一个瞬间，它所在的世界，就根据其所呼唤的 systemcall 回应了它。
+编写操作系统，其实就是在编制普通软件的世界。
+事实上，操作系统也只是在运用硬件和sbi提供给它的魔法罢了
+以上是在我眼中的 rust 和 操作系统 ，作为一个初学者，难免出现错漏和片面。
+如果读者发现什么需要指正和交流的，欢迎联系我。oveln@outlook。
+以及OvBlog
+ + +-- - - -本来想在这里放一个图片的，但是看群里好像图片不太好处理，那就不放了
-不过在这里贴一个图片仓库链接：ServiceLogos，作者画得太好看，导致我当天看到就去印贴纸了……
-
我从稍微理解了我的专业之后就一直都很崇拜 Linus，这位堪称传奇的软件工程师在 1991 年 8 月 25 日——他 21 岁时就在网络上发布了 Linux 内核的源代码。现在是 2024 年 4 月 23 日，我也是 21 岁，追逐吗，梦想吗，我也想像他一样写出这样神奇的代码，33 年后的今天，我也要开始了，Linus。
-在写这篇博客时，本人东北大学大三在读，前两年东学西学，Rust 就是之一，说实话，在本学期开始时，我实在找不到什么东西来做，准备先买一本《趣读 Linux 源码》来看，感谢我学弟翊嘉，是他给我推荐了这个操作系统训练营，这样直接上手操作系统的效果比看书要好太多了，真的十分感谢！
-我对 Rust 的理解还是比较少，future、unsafe 的内容更是知之甚少，所以大佬求带！看到我这篇总结报告之中有什么不足也请指出！
-这一阶段的练习基本上带领我加强了一遍 Rust 的语法，因为我接触 Rust 已经有小半年了，所以对我来说并不算很困难（如果要我 0 基础开始的话可能就会有点受不了了）。话虽如此， rustlings 确实给了我很多细节上的考验，我通过了它们，查缺补漏，学到了很多新东西（这里就当错题集一题一题记录了 XD）：
---2024_4_24, PS：因为这一个阶段基本上都是一些对 Rust 语法概念上的训练，所以我会着重讲一下对 Rust 一些重要语法概念的理解，本来写了挺多的，但是后面全部都删掉了，因为突然发现我好像也就是鹦鹉学舌，纯纯就是一些对官方文档还有论坛讨论的翻译，所以我会在讲到一个我觉得值得注意的点的时候把链接贴出来，然后提一下这个链接讲了什么，同学们自己去看会好的多
-
--2024_4_25, PS：感觉讲的有点乱了，实际上 Rust 之中的移动、生命周期、所有权的概念真的是耦合在一起的，在讲到一个部分的时候免不了要带一点其它两个部分。
-
说实话，移动和所有权这个语意在其他语言里面确实存在，但是一般作为规范存在，没有在 Rust 里面管的这么严，在 options3.rs 之中我就犯了这么一个错误：
我在 main 函数之中这样写道：
-1 | let y: Option<Point> = Some(Point { x: 100, y: 200 }); |
这样写会报错（value used here after partial move），因为在最后返回 y 之前 Some(p)就已经把外面 y 的所有权移动到 p 上了，此时 y 指向的是一个无效的内存空间。所以现在的解决方案就是把外面 y 借用到 Some(p)之中，一个关键字 ref 可以帮助我们做到这一点。这个关键字其实用法还是挺多的，一般用于模式匹配：
下面是一段在《Rust 编程指南》之中的阐述（在第 10 章 Pattern 小节 Refrence Patterns 部分之中，如果你看的是英文版的 PDF 的话，在 P372 可以找到对这个问题的详细描述）：
---Rust 的模式匹配支持处理引用的两个特性：Ref 模式借用匹配值的一部分，&模式匹配引用
-
我个人感觉可以这样理解：Rust 之中的模式匹配就像是在匹配一个正则表达式，&被理解位一个字面值字符，如果写&的话，就会把&引用的那个值“解离”出来，因为匹配了前面的一个&，自然就是匹配后面的这个“值”了。
呃，我又要引用《Rust 编程指南》之中的原话了（毕竟真的这本书很专业）
---In an expression, & creates a reference.I a pattern, & matches a refrence
-在一个表达式之中，&创造一个引用，在模式之中，&匹配一个引用
-
当时我也是被震撼，确实有一种对称的美对吧？其实在 rustlings 对应的有关模式匹配训练之中你就可以发现这一点：你可以使用()来创建一个元组，可以使用{}来创建一个结构体，当然就可以使用对应包含()和{}的模式匹配来把其中对应的字段解析出来，_这是一个互逆的过程_，我觉得这一点需要好好注意一下，基本上就是模式匹配直观意义上的精髓所在了。
但是 ref更像是一个正则表达式之中的元字符，用于描述匹配规则：我只想要借用匹配的值，而不是移动它们，如果想要借出可变引用的话就要使用ref mut。所以这里这样改改，加一个ref就成功了：
1 | match y { |
当然，如果匹配的数据实现了Copetrait 的话，你怎么样搞都行，但是在处理有所有权的对象的时候就必须小心处理了，这 Rust 真给我好好上了一课。
在下一部分我想要讲讲我对生命周期和所有权的理解，所以在这里我想先就着这个例子好好借题发挥，先铺垫一下。
-实际上options3.rs还能出得更加复杂一点，这种情况就要把ref和&同时用上才能解决。在options3.rs之中，该结构体之中的两个成员都是实现了Copytrait 的，那么如果有具有所有权的成员的话，应该如何处理呢？
就像是下面这种情况（实际上你可以在《Rust 程序设计》的 P374 找到它）：
-1 | struct Engine { |
如果你像上面这样写的话就好像是把一辆借来的车里头的引擎偷出来了。Rust 会降下它的神罚，引导我们做出正确的选择：
-1 | error[E0507]: cannot move out of `borrowed_car.engine` as enum variant `Some` which is behind a shared reference |
--这里忍不住想要夸一下，Rust 的错误输出真的是太好了！
-
所以既然车是借的，引擎也应该是借的对不对？这里使用 ref 来把引擎借出来就没事了。
-实际上假如你修正了上面这个ref的问题仍然会报错，😭 了：
1 | error[E0716]: temporary value dropped while borrowed |
这里涉及到一个比较微观的问题：Rust 在背后为我们做了的事。实际上很多时候我们创建的变量的生命周期就只是一个局限于语句（statement）的 temporary lifetime，Rust 为我们做了 lifetime extention 之后才能在 block 之中使用。
-在论述这个问题之前，先列一下参考文献吧：
-上面这些概念之间的关系就是： The temporary scope of an expression is the scope that is used for the temporary variable that holds the result of that expression when used in a place context。（摘自文献 3）
-注意这里的三个关键词：temporary scope、temporary variable 和 place context
-处于位置上下文（place context）的表达式就是位置表达式，它代表了一个内存位置（Paths）。这些表达式是局部变量、静态变量、解引用（*expr）表达式、数组索引表达式（expr[expr]）、字段引用（expr.f）和括号内的位置表达式（parenthesized place expressions）
突然感觉这里举一个例子会比较好：
-1 | let t = &foo(); |
实际上是：
-1 | let tmp; |
也就是说，&foo()是一个表达式，现在它处于一个位置上下文之中（&需要一个位置），所以现在需要一个 temporary variable（简称 temporary）来存储这个foo()表达式的结果，也就是上面的tmp，这个tmp的生命周期就是 temporary scope。
而且在这里还做了一个 lifetime-extension：如果没有 let 的话，实际上 temporary 在语句的末尾（遇到;）就会被销毁：
1 | &foo(); |
实际上是
-1 | { |
这个立即失效的局部变量显然不符合用户的意图。因此，我们延长 temporary 的生命周期，使其在最内层块的末尾被删除（the end of the innermost block）。
-实际上就是把原来局限于语句的生命周期提升了一个一个层次，提升到块了。
-怎么样，是不是原来好像很理所当然的一段代码都变得不那么简单了？更多有关这部分概念的解释请参考文献 1，我在这里就不赘述了。
-回到在本小节一开始提出的问题，为啥会报错？其实看报错信息就知道了，按照我们上面的思路来思考：
-首先，里面这个表达式处于一个位置上下文（place context）之中，因为&期待一个位置，所以得有一个 temporary 来保存这个位置啊：
1 | { |
但是很不幸的是，这个 temporary 首先作用于 Some，而不是 let，所以不会进行 lifetime-extension，在遇到;之后，temporary 就被 drop 掉了。
出现了，悬垂引用！Rust 就 panic 了。（本节完）
-“光的波粒二象性”这个比喻是油管的一个博主 ledoo 提出来的。
-我觉得讲的真的很不错，所以在这里想提一提。
-大概就是说，我们讲到生命周期（lifetime）就是总是从代码层面去分析对不对？去看是不是你变量的第一次声明和最后一次使用跨越了一个 block，但是实际上 Rust 做这个生命周期是为了检查内存的有效性的，你还可以从变量指向内存的位置和保证内存的有效性这两个角度来理解生命周期。（Thinking about lifetime as regions of memory, what can they——the reference point to?）
-这就好像是光的波粒二象性一样，有的时候从这个角度去看比较好理解，有的时候从另外一个角度去看则更佳。 我个人觉得用这种角度去理解生命周期标注是最好的。
-就拿 lifetimes1.rs 为例吧：
--实际上他视频里面就有讲这个很经典的生命周期标注问题
-
1 | fn longest(x: &str, y: &str) -> &str { |
这道题的正确答案应该是这样：
-1 | fn longest<'a>(x: &'a str, y: &'a str) -> &'a str { |
加上生命周期标注，生命标注在我初学 Rust 的时候把我虐的死去活来的，你比如说这里的'a，为什么大家都是标'a？是不是意味着所有传入的 reference 的生命周期都要是相同的？什么？返回值的生命周期也是'a？三个都要相同？啊？这限制也太严格了把？
当然，如果你读过像是 Rust 圣经的文档话，文档里面就会告诉你：实际上呢，这里的意思是以生命周期最小的那个 Reference 为准，不过呢……总感觉怪怪的。
-如果你使用指向有效内存的角度来进行分析的话，我感觉就会比较好一点：
-x 指向一块内存 memory_x，y 也指向一块内存 memory_y，这两块内存当然可以是不一样的，返回值也指向一块内存，那么在这里'a的作用就是说，我要统一这两块内存，返回值指向memory_x“和”memory_y。这里“和”打双引号，因为现实不可能同时指向两部分嘛。
所以 Rust 怎么检查这个返回值是否有效？答案是在这个返回值最后一次使用之前这两块内存memory_x和memory_y都要有效。
如果使用生命周期约束的话，差不多也是这个意思，比如说'a: 'b比较官方的说法就是'a的生命周期的范围必须包含或等于'b的生命周期的范围。
假如我们使用“内存说”的话，就刚刚好反过来，'b指向的内存包含了'a指向的内存，所以'b有效的时候'a也一定要有效，所以你可以这样读这个限界：'a in 'b。
嗯，大概就是这样。（本节完）
-首先，感谢你看到这里！
-本来还想写一些 unsafe 还有 cargo 的内容的，但是没有时间了！！！！！唉，期中了，我还有 ddl 要赶呢，在这篇博客之中写的生命周期、所有权、移动的概念（话说好像都在讲生命周期）我认为就是 Rust 的核心了，所以对于第一部分的 Rust 编程学习，内容分量应该也刚刚好吧？（小小的虚荣一下，把我在第一部分之中讲的那个车和引擎的问题出成题感觉也 ٩(•̤̀ᵕ•̤́๑)ᵒᵏᵎᵎᵎᵎ？）
-所以我准备移动一下，在第二阶段的报告里面把 unsafe、cargo 连着操作系统讲一下，如果你觉得从我的这篇报告学到了什么东西的话，那就太好了！
--- - -2024 年 04 月 25 日 21:14:31
-
++ + + +本来想在这里放一个图片的，但是看群里好像图片不太好处理，那就不放了
+不过在这里贴一个图片仓库链接：ServiceLogos，作者画得太好看，导致我当天看到就去印贴纸了……
+
我从稍微理解了我的专业之后就一直都很崇拜 Linus，这位堪称传奇的软件工程师在 1991 年 8 月 25 日——他 21 岁时就在网络上发布了 Linux 内核的源代码。现在是 2024 年 4 月 23 日，我也是 21 岁，追逐吗，梦想吗，我也想像他一样写出这样神奇的代码，33 年后的今天，我也要开始了，Linus。
+在写这篇博客时，本人东北大学大三在读，前两年东学西学，Rust 就是之一，说实话，在本学期开始时，我实在找不到什么东西来做，准备先买一本《趣读 Linux 源码》来看，感谢我学弟翊嘉，是他给我推荐了这个操作系统训练营，这样直接上手操作系统的效果比看书要好太多了，真的十分感谢！
+我对 Rust 的理解还是比较少，future、unsafe 的内容更是知之甚少，所以大佬求带！看到我这篇总结报告之中有什么不足也请指出！
+这一阶段的练习基本上带领我加强了一遍 Rust 的语法，因为我接触 Rust 已经有小半年了，所以对我来说并不算很困难（如果要我 0 基础开始的话可能就会有点受不了了）。话虽如此， rustlings 确实给了我很多细节上的考验，我通过了它们，查缺补漏，学到了很多新东西（这里就当错题集一题一题记录了 XD）：
+++2024_4_24, PS：因为这一个阶段基本上都是一些对 Rust 语法概念上的训练，所以我会着重讲一下对 Rust 一些重要语法概念的理解，本来写了挺多的，但是后面全部都删掉了，因为突然发现我好像也就是鹦鹉学舌，纯纯就是一些对官方文档还有论坛讨论的翻译，所以我会在讲到一个我觉得值得注意的点的时候把链接贴出来，然后提一下这个链接讲了什么，同学们自己去看会好的多
+
++2024_4_25, PS：感觉讲的有点乱了，实际上 Rust 之中的移动、生命周期、所有权的概念真的是耦合在一起的，在讲到一个部分的时候免不了要带一点其它两个部分。
+
说实话，移动和所有权这个语意在其他语言里面确实存在，但是一般作为规范存在，没有在 Rust 里面管的这么严，在 options3.rs 之中我就犯了这么一个错误：
我在 main 函数之中这样写道：
+1 | let y: Option<Point> = Some(Point { x: 100, y: 200 }); |
这样写会报错（value used here after partial move），因为在最后返回 y 之前 Some(p)就已经把外面 y 的所有权移动到 p 上了，此时 y 指向的是一个无效的内存空间。所以现在的解决方案就是把外面 y 借用到 Some(p)之中，一个关键字 ref 可以帮助我们做到这一点。这个关键字其实用法还是挺多的，一般用于模式匹配：
下面是一段在《Rust 编程指南》之中的阐述（在第 10 章 Pattern 小节 Refrence Patterns 部分之中，如果你看的是英文版的 PDF 的话，在 P372 可以找到对这个问题的详细描述）：
+++Rust 的模式匹配支持处理引用的两个特性：Ref 模式借用匹配值的一部分，&模式匹配引用
+
我个人感觉可以这样理解：Rust 之中的模式匹配就像是在匹配一个正则表达式，&被理解位一个字面值字符，如果写&的话，就会把&引用的那个值“解离”出来，因为匹配了前面的一个&，自然就是匹配后面的这个“值”了。
呃，我又要引用《Rust 编程指南》之中的原话了（毕竟真的这本书很专业）
+++In an expression, & creates a reference.I a pattern, & matches a refrence
+在一个表达式之中，&创造一个引用，在模式之中，&匹配一个引用
+
当时我也是被震撼，确实有一种对称的美对吧？其实在 rustlings 对应的有关模式匹配训练之中你就可以发现这一点：你可以使用()来创建一个元组，可以使用{}来创建一个结构体，当然就可以使用对应包含()和{}的模式匹配来把其中对应的字段解析出来，_这是一个互逆的过程_，我觉得这一点需要好好注意一下，基本上就是模式匹配直观意义上的精髓所在了。
但是 ref更像是一个正则表达式之中的元字符，用于描述匹配规则：我只想要借用匹配的值，而不是移动它们，如果想要借出可变引用的话就要使用ref mut。所以这里这样改改，加一个ref就成功了：
1 | match y { |
当然，如果匹配的数据实现了Copetrait 的话，你怎么样搞都行，但是在处理有所有权的对象的时候就必须小心处理了，这 Rust 真给我好好上了一课。
在下一部分我想要讲讲我对生命周期和所有权的理解，所以在这里我想先就着这个例子好好借题发挥，先铺垫一下。
+实际上options3.rs还能出得更加复杂一点，这种情况就要把ref和&同时用上才能解决。在options3.rs之中，该结构体之中的两个成员都是实现了Copytrait 的，那么如果有具有所有权的成员的话，应该如何处理呢？
就像是下面这种情况（实际上你可以在《Rust 程序设计》的 P374 找到它）：
+1 | struct Engine { |
如果你像上面这样写的话就好像是把一辆借来的车里头的引擎偷出来了。Rust 会降下它的神罚，引导我们做出正确的选择：
+1 | error[E0507]: cannot move out of `borrowed_car.engine` as enum variant `Some` which is behind a shared reference |
++这里忍不住想要夸一下，Rust 的错误输出真的是太好了！
+
所以既然车是借的，引擎也应该是借的对不对？这里使用 ref 来把引擎借出来就没事了。
+实际上假如你修正了上面这个ref的问题仍然会报错，😭 了：
1 | error[E0716]: temporary value dropped while borrowed |
这里涉及到一个比较微观的问题：Rust 在背后为我们做了的事。实际上很多时候我们创建的变量的生命周期就只是一个局限于语句（statement）的 temporary lifetime，Rust 为我们做了 lifetime extention 之后才能在 block 之中使用。
+在论述这个问题之前，先列一下参考文献吧：
+上面这些概念之间的关系就是： The temporary scope of an expression is the scope that is used for the temporary variable that holds the result of that expression when used in a place context。（摘自文献 3）
+注意这里的三个关键词：temporary scope、temporary variable 和 place context
+处于位置上下文（place context）的表达式就是位置表达式，它代表了一个内存位置（Paths）。这些表达式是局部变量、静态变量、解引用（*expr）表达式、数组索引表达式（expr[expr]）、字段引用（expr.f）和括号内的位置表达式（parenthesized place expressions）
突然感觉这里举一个例子会比较好：
+1 | let t = &foo(); |
实际上是：
+1 | let tmp; |
也就是说，&foo()是一个表达式，现在它处于一个位置上下文之中（&需要一个位置），所以现在需要一个 temporary variable（简称 temporary）来存储这个foo()表达式的结果，也就是上面的tmp，这个tmp的生命周期就是 temporary scope。
而且在这里还做了一个 lifetime-extension：如果没有 let 的话，实际上 temporary 在语句的末尾（遇到;）就会被销毁：
1 | &foo(); |
实际上是
+1 | { |
这个立即失效的局部变量显然不符合用户的意图。因此，我们延长 temporary 的生命周期，使其在最内层块的末尾被删除（the end of the innermost block）。
+实际上就是把原来局限于语句的生命周期提升了一个一个层次，提升到块了。
+怎么样，是不是原来好像很理所当然的一段代码都变得不那么简单了？更多有关这部分概念的解释请参考文献 1，我在这里就不赘述了。
+回到在本小节一开始提出的问题，为啥会报错？其实看报错信息就知道了，按照我们上面的思路来思考：
+首先，里面这个表达式处于一个位置上下文（place context）之中，因为&期待一个位置，所以得有一个 temporary 来保存这个位置啊：
1 | { |
但是很不幸的是，这个 temporary 首先作用于 Some，而不是 let，所以不会进行 lifetime-extension，在遇到;之后，temporary 就被 drop 掉了。
出现了，悬垂引用！Rust 就 panic 了。（本节完）
+“光的波粒二象性”这个比喻是油管的一个博主 ledoo 提出来的。
+我觉得讲的真的很不错，所以在这里想提一提。
+大概就是说，我们讲到生命周期（lifetime）就是总是从代码层面去分析对不对？去看是不是你变量的第一次声明和最后一次使用跨越了一个 block，但是实际上 Rust 做这个生命周期是为了检查内存的有效性的，你还可以从变量指向内存的位置和保证内存的有效性这两个角度来理解生命周期。（Thinking about lifetime as regions of memory, what can they——the reference point to?）
+这就好像是光的波粒二象性一样，有的时候从这个角度去看比较好理解，有的时候从另外一个角度去看则更佳。 我个人觉得用这种角度去理解生命周期标注是最好的。
+就拿 lifetimes1.rs 为例吧：
++实际上他视频里面就有讲这个很经典的生命周期标注问题
+
1 | fn longest(x: &str, y: &str) -> &str { |
这道题的正确答案应该是这样：
+1 | fn longest<'a>(x: &'a str, y: &'a str) -> &'a str { |
加上生命周期标注，生命标注在我初学 Rust 的时候把我虐的死去活来的，你比如说这里的'a，为什么大家都是标'a？是不是意味着所有传入的 reference 的生命周期都要是相同的？什么？返回值的生命周期也是'a？三个都要相同？啊？这限制也太严格了把？
当然，如果你读过像是 Rust 圣经的文档话，文档里面就会告诉你：实际上呢，这里的意思是以生命周期最小的那个 Reference 为准，不过呢……总感觉怪怪的。
+如果你使用指向有效内存的角度来进行分析的话，我感觉就会比较好一点：
+x 指向一块内存 memory_x，y 也指向一块内存 memory_y，这两块内存当然可以是不一样的，返回值也指向一块内存，那么在这里'a的作用就是说，我要统一这两块内存，返回值指向memory_x“和”memory_y。这里“和”打双引号，因为现实不可能同时指向两部分嘛。
所以 Rust 怎么检查这个返回值是否有效？答案是在这个返回值最后一次使用之前这两块内存memory_x和memory_y都要有效。
如果使用生命周期约束的话，差不多也是这个意思，比如说'a: 'b比较官方的说法就是'a的生命周期的范围必须包含或等于'b的生命周期的范围。
假如我们使用“内存说”的话，就刚刚好反过来，'b指向的内存包含了'a指向的内存，所以'b有效的时候'a也一定要有效，所以你可以这样读这个限界：'a in 'b。
嗯，大概就是这样。（本节完）
+首先，感谢你看到这里！
+本来还想写一些 unsafe 还有 cargo 的内容的，但是没有时间了！！！！！唉，期中了，我还有 ddl 要赶呢，在这篇博客之中写的生命周期、所有权、移动的概念（话说好像都在讲生命周期）我认为就是 Rust 的核心了，所以对于第一部分的 Rust 编程学习，内容分量应该也刚刚好吧？（小小的虚荣一下，把我在第一部分之中讲的那个车和引擎的问题出成题感觉也 ٩(•̤̀ᵕ•̤́๑)ᵒᵏᵎᵎᵎᵎ？）
+所以我准备移动一下，在第二阶段的报告里面把 unsafe、cargo 连着操作系统讲一下，如果你觉得从我的这篇报告学到了什么东西的话，那就太好了！
+++ + +2024 年 04 月 25 日 21:14:31
+
练习1是输出彩色字体，实现并不难。
+练习2是移植hashmap，我将标准库里的 hashmap 拷贝过来，先全部注释掉，再根据测试结果逐步的去解除注释
+练习三和四是实现内存分配算法和解析 fdt，解析 fdt 使用了群友推荐的库。
+练习5是抢占式的 fifo，只需要将 rr 里面的抢占的代码移植过来
+镜像格式：
+|app_num|app_size|app_data|app_size|app_data|…|
+一开始使用dd写入的时候一直无法读取第二个app，后来通过 hexdump 去解析镜像文件发现了问题在哪，进行了相应的修改。
+需要去掉 noreturn，让函数返回
+练习3使用 axstd 里面提供的 exit 方法就可以完成这个实验
+练习4需要注意寄存器 a7 被 rust 修改，每次调用完后需要重新设置 a7 的值，或者第一次返回的时候就保存好入口地址，以后就使用这个入口地址，还需要加上clobber_abi("C")。遍历字符串的时候使用 bytes 来迭代。
需要先读取 app_num 和 app_size。其他就移植练习5过来就行。
+ + + +--main 函数中，固定设置 app_size = 32，这个显然是不合理甚至危险的。
-
请为 image 设计一个头结构，包含应用的长度信息，loader 在加载应用时获取它的实际大小。
一开始想要尝试类似于rcore中在链接脚本的特定位置保存数据并且通过build.rs脚本获取对应镜像大小然后再写入到链接文件中去的方法。
-后面想到这个方法会因为相互依赖问题而不容易解决，最原初的设想在于类似rCore的处理方案，在原初的链接脚本中保存一个位置用于存储应用程序大小，后面在loader中对于这个段的数据进行获取，但是这部操作实际上是需要在链接的时候完成的，即我还不知道最终生成的二进制文件的大小就要将其写入进去。（后面想了下可能还可以在外面手动修改这个段，但是有点麻烦了就没有使用）。
-在与邝劲强同学进行沟通的时候，发现其实可以用相对来说更加简单的方法来实现这个效果，即通过一个脚本实现了对于镜像文件大小的获取以及自动将代表对应文件大小的bin文件加载到对应的位置。这个地方特别感谢邝劲强同学分享的有关 dd 会相互覆盖，可以使用 seek 跳过一段的信息。
1 | APP_BIN_SIZE=$(stat -c%s "./hello_app.bin") |
image头结构，使之可包含两个应用。通过对于 hello_app 的简单拷贝，可以实现第二个应用，这一步主要是在一开始的基础上拓展了头结构，但是由于这里没有提供对于更多应用程序的支持以及通过函数返回了文件大小埋了个坑（后面会提到）。
1 | # Input: The Name of Directory |
nop 和 wfi这里有个小问题就是需要修改原始代码中给出的 -> ! 和 options(noreturn) 标志，以避免出现没有办法返回的情况。
这个地方实际上实现的批处理并不是真正意义上的批处理，我在复用之前代码的时候出错了，这个问题在 lab2.5-commit 中得到了修复。
-以下是当时提交的实现，基本上就是对之前的代码的直接复用。
-1 | let apps_start = PLASH_START as *const u8; |
SYS_TERMINATE这个练习没什么好说的，直接添加 arceos_api 然后再加到符号表里面实现一下功能就可以了
1 | fn abi_terminate() -> ! { |
hello_app在完成实验五的时候主要出现了几个超出意料而且有点摸不着头脑的情况，包括但不限于a7寄存器被修改，莫名其妙的镜像文件截断，主要的修复细节可以参考 批处理修复，多道程序支持，返回值错误修复，拷贝错误修复，寄存器错误修复 等具体 commit。
本任务的主体部分实际上与之前的exec2.4没有什么特别的差异，主要的难点在于puts的实现实际上调用了迭代器的功能，同时这还牵涉到由于字符串实现中&str的链接问题。
1.由于在操作中使用了字符串，但是字符串被放置在rodata段，在默认链接情况下rodata段实际上位于.text段前面，这会违背我们以装载地址作为应用的起始运行地址的想法（jalr LOAD_ADDRESS）【在起始部分有一大串0】
因此，需要手动实现一个类似的链接脚本（本处直接采用了rCore之前使用的链接脚本进行替代），添加build.rs编译脚本，给cargo添加了rust-args参数以选择我们自己做的链接脚本对于hello_app包进行链接。此处特别鸣谢赫森同学在群里分享的有关信息。
2.在修改了链接脚本之后仍然会出现神奇的报错信息，经过修改 MakeFile 运行 debug 之后发生产生这个情况的原因在于程序的二进制文件被异常截断了，同时出现很神奇的文件大小不增反减的情况（如下图）。
这跟我之前exec2.2实现的那个函数有直接的关联，或者说主要的问题就处在我使用的这个函数这里。
-1 | # exec 2.2 实现的函数 |
王瑞康同学指出我的脚本代码中实际存在缺陷，问题主要出在我这个地方是通过bash函数的返回值来实现对于镜像文件大小的获取，但是实际上这个地方由于bash函数返回值限制在0~255位， 当添加了&str之后的镜像文件大小实际上达到了将近4110，则会面临取模截断的情况，在这样情况下4110 % 256 = 13 最终导致了实际上只有13个字节的数据被成功加载到内存中来，最终导致了代码出现异常的截断情况。
-针对于这个情况，主要修复的方案在于通过echo + result=${}，外加事先转换成为十六进制。
-1 | # Input: The Name of Directory |
panic，经过调试之后发现，主要问题出现在 a7 寄存器被擦写。针对于这个问题，在之前的练习四多次调用同一个函数的时候也回出现类似的错误，当时进行修复的主要是在函数调用末尾添加了unsafe { core::arch::asm!("ld a7, {}), sym ABI_TABLE}，在每一个可能使用到 a7 寄存器的地方手动添加一次寄存器，但是在使用迭代器的情况下，这种简单的处理方法并不奏效。根据群里面王瑞康同学分享的clobber_abi("C")，在应用程序调用asm的时候添加了这个操作就可以保持寄存器不变。
练习五的时候由于接受了赫森和邝劲强同学有关于当前脚本不能很好的适应多道程序加载的建议（裱糊匠操作太多），对于原先的脚本进行了重构，重构后仅需要以字符串形式在脚本中添加对应的应用名称，就可以自动将应用生成二进制文件放到一起。
-1 | // 注：这个地方实际上搞错了PFLASH的具体位置，但是懒得改了 |
这段主要实现的交过类似于前文中所实现的，具体包括生成应用程序脚本并且通过objcopy去除其中非必要的信息，通过echo的方式传递对应的数据。
用下文中的for循环包裹上面的这个函数，实现了将对应的app_name, app_size等数据保存在bash一维数组中的效果（方便后文调用）
1 | for name in "${app_names[@]}"; do |
根据上面获取到的对应size信息，自动生成有关于num和size的数据，并且分别生成十六进制二进制文件合并到原先的PFALSH空间中。
-1 | cd $BASE_DIR |
然后，根据上文中保存的对应数据，自动生成其他的，涵盖包信息的二进制文件，并且逐个合并到前面的空间中。
-1 | start_offset=$((2 + 4 * $NUM_OF_IMAGE)) # NUM_OF_IMAGE:2B + IMAGE_SIZE:4B * NUM_OF_IMAGE |
在loader中，主要做出了如下改变：
-首先，根据当前的二进制布局，获取app_num作为总应用程序数量研判标准，获取对应各个应用程序sizes的区域
-let byte_num = unsafe { core::slice::from_raw_parts(apps_start, size_of::
let app_num = u8::from_be_bytes([byte_num[0]]);
保存操作如下：
-其中需要特别注意到的是由于rust中的自动union操作（忘记叫啥名了，就是自动对齐），会对于u8,u16连续的情况下在u8之后补零
1 | // Gain Each App Size |
并且将其存储到结构体数组中：
结构体实现如下：
1 |
|
最后通过一个for循环实现重复装载应用程序到指定地址
-1 | // LOAD APPLICATION |
基本上没什么好说的，对于base2.5的代码进行简单复用就可以实现。
++main 函数中，固定设置 app_size = 32，这个显然是不合理甚至危险的。
+
请为 image 设计一个头结构，包含应用的长度信息，loader 在加载应用时获取它的实际大小。
一开始想要尝试类似于rcore中在链接脚本的特定位置保存数据并且通过build.rs脚本获取对应镜像大小然后再写入到链接文件中去的方法。
+后面想到这个方法会因为相互依赖问题而不容易解决，最原初的设想在于类似rCore的处理方案，在原初的链接脚本中保存一个位置用于存储应用程序大小，后面在loader中对于这个段的数据进行获取，但是这部操作实际上是需要在链接的时候完成的，即我还不知道最终生成的二进制文件的大小就要将其写入进去。（后面想了下可能还可以在外面手动修改这个段，但是有点麻烦了就没有使用）。
+在与邝劲强同学进行沟通的时候，发现其实可以用相对来说更加简单的方法来实现这个效果，即通过一个脚本实现了对于镜像文件大小的获取以及自动将代表对应文件大小的bin文件加载到对应的位置。这个地方特别感谢邝劲强同学分享的有关 dd 会相互覆盖，可以使用 seek 跳过一段的信息。
1 | APP_BIN_SIZE=$(stat -c%s "./hello_app.bin") |
image头结构，使之可包含两个应用。通过对于 hello_app 的简单拷贝，可以实现第二个应用，这一步主要是在一开始的基础上拓展了头结构，但是由于这里没有提供对于更多应用程序的支持以及通过函数返回了文件大小埋了个坑（后面会提到）。
1 | # Input: The Name of Directory |
nop 和 wfi这里有个小问题就是需要修改原始代码中给出的 -> ! 和 options(noreturn) 标志，以避免出现没有办法返回的情况。
这个地方实际上实现的批处理并不是真正意义上的批处理，我在复用之前代码的时候出错了，这个问题在 lab2.5-commit 中得到了修复。
+以下是当时提交的实现，基本上就是对之前的代码的直接复用。
+1 | let apps_start = PLASH_START as *const u8; |
SYS_TERMINATE这个练习没什么好说的，直接添加 arceos_api 然后再加到符号表里面实现一下功能就可以了
1 | fn abi_terminate() -> ! { |
hello_app在完成实验五的时候主要出现了几个超出意料而且有点摸不着头脑的情况，包括但不限于a7寄存器被修改，莫名其妙的镜像文件截断，主要的修复细节可以参考 批处理修复，多道程序支持，返回值错误修复，拷贝错误修复，寄存器错误修复 等具体 commit。
本任务的主体部分实际上与之前的exec2.4没有什么特别的差异，主要的难点在于puts的实现实际上调用了迭代器的功能，同时这还牵涉到由于字符串实现中&str的链接问题。
1.由于在操作中使用了字符串，但是字符串被放置在rodata段，在默认链接情况下rodata段实际上位于.text段前面，这会违背我们以装载地址作为应用的起始运行地址的想法（jalr LOAD_ADDRESS）【在起始部分有一大串0】
因此，需要手动实现一个类似的链接脚本（本处直接采用了rCore之前使用的链接脚本进行替代），添加build.rs编译脚本，给cargo添加了rust-args参数以选择我们自己做的链接脚本对于hello_app包进行链接。此处特别鸣谢赫森同学在群里分享的有关信息。
2.在修改了链接脚本之后仍然会出现神奇的报错信息，经过修改 MakeFile 运行 debug 之后发生产生这个情况的原因在于程序的二进制文件被异常截断了，同时出现很神奇的文件大小不增反减的情况（如下图）。
这跟我之前exec2.2实现的那个函数有直接的关联，或者说主要的问题就处在我使用的这个函数这里。
+1 | # exec 2.2 实现的函数 |
王瑞康同学指出我的脚本代码中实际存在缺陷，问题主要出在我这个地方是通过bash函数的返回值来实现对于镜像文件大小的获取，但是实际上这个地方由于bash函数返回值限制在0~255位， 当添加了&str之后的镜像文件大小实际上达到了将近4110，则会面临取模截断的情况，在这样情况下4110 % 256 = 13 最终导致了实际上只有13个字节的数据被成功加载到内存中来，最终导致了代码出现异常的截断情况。
+针对于这个情况，主要修复的方案在于通过echo + result=${}，外加事先转换成为十六进制。
+1 | # Input: The Name of Directory |
panic，经过调试之后发现，主要问题出现在 a7 寄存器被擦写。针对于这个问题，在之前的练习四多次调用同一个函数的时候也回出现类似的错误，当时进行修复的主要是在函数调用末尾添加了unsafe { core::arch::asm!("ld a7, {}), sym ABI_TABLE}，在每一个可能使用到 a7 寄存器的地方手动添加一次寄存器，但是在使用迭代器的情况下，这种简单的处理方法并不奏效。根据群里面王瑞康同学分享的clobber_abi("C")，在应用程序调用asm的时候添加了这个操作就可以保持寄存器不变。
练习五的时候由于接受了赫森和邝劲强同学有关于当前脚本不能很好的适应多道程序加载的建议（裱糊匠操作太多），对于原先的脚本进行了重构，重构后仅需要以字符串形式在脚本中添加对应的应用名称，就可以自动将应用生成二进制文件放到一起。
+1 | // 注：这个地方实际上搞错了PFLASH的具体位置，但是懒得改了 |
这段主要实现的交过类似于前文中所实现的，具体包括生成应用程序脚本并且通过objcopy去除其中非必要的信息，通过echo的方式传递对应的数据。
用下文中的for循环包裹上面的这个函数，实现了将对应的app_name, app_size等数据保存在bash一维数组中的效果（方便后文调用）
1 | for name in "${app_names[@]}"; do |
根据上面获取到的对应size信息，自动生成有关于num和size的数据，并且分别生成十六进制二进制文件合并到原先的PFALSH空间中。
+1 | cd $BASE_DIR |
然后，根据上文中保存的对应数据，自动生成其他的，涵盖包信息的二进制文件，并且逐个合并到前面的空间中。
+1 | start_offset=$((2 + 4 * $NUM_OF_IMAGE)) # NUM_OF_IMAGE:2B + IMAGE_SIZE:4B * NUM_OF_IMAGE |
在loader中，主要做出了如下改变：
+首先，根据当前的二进制布局，获取app_num作为总应用程序数量研判标准，获取对应各个应用程序sizes的区域
+let byte_num = unsafe { core::slice::from_raw_parts(apps_start, size_of::
let app_num = u8::from_be_bytes([byte_num[0]]);
保存操作如下：
+其中需要特别注意到的是由于rust中的自动union操作（忘记叫啥名了，就是自动对齐），会对于u8,u16连续的情况下在u8之后补零
1 | // Gain Each App Size |
并且将其存储到结构体数组中：
结构体实现如下：
1 |
|
最后通过一个for循环实现重复装载应用程序到指定地址
+1 | // LOAD APPLICATION |
基本上没什么好说的，对于base2.5的代码进行简单复用就可以实现。
在实验1中，我们需要实现一个sys_task_info的系统调用，用于获取进程的信息。首先，我们要能够返回task运行的总时间，即第一次执行时间到当前时间的时间差，单位为ms，要实现这个功能，我在TaskControlBlock结构体中添加了我需要的开始时间戳，然后在第一次run该task的时候，记录开始时间戳，然后在sys_task_info中，通过current_task，找到对应的TaskControlBlock，然后计算时间差，返回即可。第二步，能够统计task的sys_call的调用次数，同上，我在TaskControlBlock结构体中添加了我需要的sys_call调用次数，然后在每次调用sys_call的时候，增加该系统调用的调用次数即trap_handler中抓取到系统调用的中断处理时处理即可，然后在sys_task_info中，通过current_task，找到对应的TaskControlBlock，然后返回即可。
-实验2使用 Rust 的全局的动态内存分配器的实现 buddy_system_allocator 完成在内核中使用堆空间。 基于 RISC-V 硬件支持的 SV39 多级页表实现地址空间、物理页的分配与回收。开始划分内核地址空间及应用地址空间，实现应用程序不在需要关注应用起始地址及存放位置。相比上一章节的中断和系统调用处理过程添加了跳板页面，来避免在用户模式进入内核模式或内核模式退回用户模式时导致的地址不一致。
lab2 实验中 lab1 实验的相关内容需要重新实现，因为内存分页后在用户态传递进来的参数地址是虚拟地址，内核的访问地址映射和物理地址一致，无法通过虚拟地址对传递进来的参数赋值，所以需要将虚拟地址转换为物理地址，才能完成赋值。 sys_mmap 的实现参考系统中 insert_framed_area 的实现，添加逻辑校验给定的地址中是否包含已经映射的地址即可。sys_munmap 根据 sys_mmap 的实现反推即可实现。
在实验3中，ch3 中我学习了多道程序的放置与加载，任务切换，如何管理多道程序。然后在练习中为了实现 sys_task_info 我在原本 TaskControlBlock 的基础上添加了 task_syscall_times 数组和 first_start_time 字段来记录获取 taskinfo 所需信息。在 syscall 中调用自己封装的 add_cuurent_task_syscall_times 来实现对 task_syscall_times 记录更新。而对于 first_start_time，我在程序第一次运行时更新来记录，使得在调用 sys_task_info 时能够准确获得程序的运行时长。
-第一次接触结构如此清晰的OS课设，从历史演变的角度一步步搭建操作系统，每章的讲解图文并茂，将内核的功能与结构十分直观地剖析了出来。在遇到问题时老师们的讲解也帮助了我很多。
- - -在实验1中，我们需要实现一个sys_task_info的系统调用，用于获取进程的信息。首先，我们要能够返回task运行的总时间，即第一次执行时间到当前时间的时间差，单位为ms，要实现这个功能，我在TaskControlBlock结构体中添加了我需要的开始时间戳，然后在第一次run该task的时候，记录开始时间戳，然后在sys_task_info中，通过current_task，找到对应的TaskControlBlock，然后计算时间差，返回即可。第二步，能够统计task的sys_call的调用次数，同上，我在TaskControlBlock结构体中添加了我需要的sys_call调用次数，然后在每次调用sys_call的时候，增加该系统调用的调用次数即trap_handler中抓取到系统调用的中断处理时处理即可，然后在sys_task_info中，通过current_task，找到对应的TaskControlBlock，然后返回即可。
+实验2使用 Rust 的全局的动态内存分配器的实现 buddy_system_allocator 完成在内核中使用堆空间。 基于 RISC-V 硬件支持的 SV39 多级页表实现地址空间、物理页的分配与回收。开始划分内核地址空间及应用地址空间，实现应用程序不在需要关注应用起始地址及存放位置。相比上一章节的中断和系统调用处理过程添加了跳板页面，来避免在用户模式进入内核模式或内核模式退回用户模式时导致的地址不一致。
lab2 实验中 lab1 实验的相关内容需要重新实现，因为内存分页后在用户态传递进来的参数地址是虚拟地址，内核的访问地址映射和物理地址一致，无法通过虚拟地址对传递进来的参数赋值，所以需要将虚拟地址转换为物理地址，才能完成赋值。 sys_mmap 的实现参考系统中 insert_framed_area 的实现，添加逻辑校验给定的地址中是否包含已经映射的地址即可。sys_munmap 根据 sys_mmap 的实现反推即可实现。
在实验3中，ch3 中我学习了多道程序的放置与加载，任务切换，如何管理多道程序。然后在练习中为了实现 sys_task_info 我在原本 TaskControlBlock 的基础上添加了 task_syscall_times 数组和 first_start_time 字段来记录获取 taskinfo 所需信息。在 syscall 中调用自己封装的 add_cuurent_task_syscall_times 来实现对 task_syscall_times 记录更新。而对于 first_start_time，我在程序第一次运行时更新来记录，使得在调用 sys_task_info 时能够准确获得程序的运行时长。
+第一次接触结构如此清晰的OS课设，从历史演变的角度一步步搭建操作系统，每章的讲解图文并茂，将内核的功能与结构十分直观地剖析了出来。在遇到问题时老师们的讲解也帮助了我很多。
+ + +如果使用8g内存的m1 mac来做实验的话推荐使用docker来做，相较于vmware来说docker的内存占用会更低一些（8g内存开个虚拟机和vscode挂几个网页基本上就压力就变黄了，要是再挂着qq、微信可能会直接变红），另外我的vmwaretools安装了也无法正常使用，我想在虚拟机内使用宿主机代理折腾了几天也没能实现，但是在docker上就很容易成功，还有就是arm64linux的软件支持比较少（科学上网方面），docker上的环境配置见 https://docs.qq.com/doc/DWW1GZ3FQekx5dm9T 第24个官方的文档里说可以直接在m1 mac上跑rcore，我成功跑通了，首先需要下载和编译riscvtools，
-下载得科学上网并且非常耗费流量（我使用镜像失败了），编译这个过程得花费一到两个小时，我试过使用他们编译好的但是无法运行，具体步骤可以参考 https://cloud.tencent.com/developer/article/1939023 然后就是下载依赖
-brew install gawk gnu-sed gmp mpfr libmpc isl zlib expat
-以及qemu建议选择qemu7.0.0（老版本qemu需要补丁 https://github.com/BASARANOMO/xv6-labs-2020/issues/1 ）
-接下来具体步骤可以参考实验书以及
-https://risc-v-getting-started-guide.readthedocs.io/en/latest/linux-qemu.html#prerequisites
-make这步由于mac上的make只有老版本所以应该得使用gmake
-make -j$(nproc) //这步需要先安装nproc，如果这步使用make报错了的话使用gmake
-接下来就可以克隆仓库运行了，跑ch1没有任何问题但是我运行后面几个实验的时候经常会遇到报错，网上也没有解决办法，所以不建议使用这个方法第一个实验要实现sys_task_info系统调用，首先在TaskControlBlock中添加syscall_times和start_time，同时在new中更新添加，接下来要实现系统调用次数信息的更新，我在内核的调度函数 run_next_task 中增加了一个简单的判断逻辑，以确定是否是进程的第一次被调度，并在需要时初始化 start_time。第二个实验需要重写 sys_get_time 和 sys_task_info, sys_get_time 的主要功能是获取当前时间并填充传递给系统调用的 TimeVal 结构。首先获取时间戳，然后将其转化为秒和微秒，填充到 TimeVal 结构中，最后将数据复制到用户空间的 ts 指针所指向的内存区域。sys_task_info 用于获取当前任务的信息，包括任务状态、系统调用次数和任务运行时间。首先通过相关函数获取这些信息，然后填充到 TaskInfo 结构中，最后将数据复制到用户空间的 ti 指针所指向的内存区域。第三个实验要实现 spawn 系统调用，首先，获取当前任务的控制块 task。使用 translated_str 函数将传递的路径 path 转化为字符串。检查是否可以找到与给定路径匹配的 ELF 数据，如果找到了 ELF 数据，就继续进行后续步骤，否则返回 -1。
-用 ELF 数据创建新的内存集合，为新进程分配一个进程 ID（PID）和一个内核堆栈。接下来创建一个新的任务控制块，该控制块包含了新进程的信息，如 PID、内核堆栈、内存集合等。将新任务控制块添加到当前任务的子任务列表中，表示当前任务是新任务的父任务。最后，将新任务添加到任务管理器中，并返回新任务的 PID。关于stride调度算法实现我参考了
-https://hangx-ma.github.io/2023/07/07/rcore-note-ch5.html如果使用8g内存的m1 mac来做实验的话推荐使用docker来做，相较于vmware来说docker的内存占用会更低一些（8g内存开个虚拟机和vscode挂几个网页基本上就压力就变黄了，要是再挂着qq、微信可能会直接变红），另外我的vmwaretools安装了也无法正常使用，我想在虚拟机内使用宿主机代理折腾了几天也没能实现，但是在docker上就很容易成功，还有就是arm64linux的软件支持比较少（科学上网方面），docker上的环境配置见 https://docs.qq.com/doc/DWW1GZ3FQekx5dm9T 第24个官方的文档里说可以直接在m1 mac上跑rcore，我成功跑通了，首先需要下载和编译riscvtools，
+下载得科学上网并且非常耗费流量（我使用镜像失败了），编译这个过程得花费一到两个小时，我试过使用他们编译好的但是无法运行，具体步骤可以参考 https://cloud.tencent.com/developer/article/1939023 然后就是下载依赖
+brew install gawk gnu-sed gmp mpfr libmpc isl zlib expat
+以及qemu建议选择qemu7.0.0（老版本qemu需要补丁 https://github.com/BASARANOMO/xv6-labs-2020/issues/1 ）
+接下来具体步骤可以参考实验书以及
+https://risc-v-getting-started-guide.readthedocs.io/en/latest/linux-qemu.html#prerequisites
+make这步由于mac上的make只有老版本所以应该得使用gmake
+make -j$(nproc) //这步需要先安装nproc，如果这步使用make报错了的话使用gmake
+接下来就可以克隆仓库运行了，跑ch1没有任何问题但是我运行后面几个实验的时候经常会遇到报错，网上也没有解决办法，所以不建议使用这个方法第一个实验要实现sys_task_info系统调用，首先在TaskControlBlock中添加syscall_times和start_time，同时在new中更新添加，接下来要实现系统调用次数信息的更新，我在内核的调度函数 run_next_task 中增加了一个简单的判断逻辑，以确定是否是进程的第一次被调度，并在需要时初始化 start_time。第二个实验需要重写 sys_get_time 和 sys_task_info, sys_get_time 的主要功能是获取当前时间并填充传递给系统调用的 TimeVal 结构。首先获取时间戳，然后将其转化为秒和微秒，填充到 TimeVal 结构中，最后将数据复制到用户空间的 ts 指针所指向的内存区域。sys_task_info 用于获取当前任务的信息，包括任务状态、系统调用次数和任务运行时间。首先通过相关函数获取这些信息，然后填充到 TaskInfo 结构中，最后将数据复制到用户空间的 ti 指针所指向的内存区域。第三个实验要实现 spawn 系统调用，首先，获取当前任务的控制块 task。使用 translated_str 函数将传递的路径 path 转化为字符串。检查是否可以找到与给定路径匹配的 ELF 数据，如果找到了 ELF 数据，就继续进行后续步骤，否则返回 -1。
+用 ELF 数据创建新的内存集合，为新进程分配一个进程 ID（PID）和一个内核堆栈。接下来创建一个新的任务控制块，该控制块包含了新进程的信息，如 PID、内核堆栈、内存集合等。将新任务控制块添加到当前任务的子任务列表中，表示当前任务是新任务的父任务。最后，将新任务添加到任务管理器中，并返回新任务的 PID。关于stride调度算法实现我参考了
+https://hangx-ma.github.io/2023/07/07/rcore-note-ch5.html 参与本次开源操作系统训练营，我开始学习了rust语言,rust语言的官方文档做得很好，rust语言圣经也很方便学习。不得不说，rust语言的学习十分陡峭，虽然在一阶段写了rustlings，在第二阶段完成了前三个lab，但是我感觉我对rust的语言理解还在比较浅的层次，生命周期和所有权的概念还有待加强，有时候我感觉我写的rust代码并不够rust,还是停留以前其他的编程语言观念，实际写代码的过程都是编译器在教导我如何写代码，通过报错和查看文档来解决问题。然后rcore的文档十分完整，既有操作系统概念上的阐述与总结，又有实践层面上的代码解释。在学习的过程中，我又加深了对操作系统的理解。
+ 能够完成各个LAB的关键，是在于理解本章实现的操作系统的各个模块负责的功能，在通过阅读文档的解释，以及阅读代码进行理解后，才能知道要应该在哪个模块添加代码以实现功能。
+ 本章的操作系统是多道程序与分时操作系统，主要是需要理清多道程序是如何调度的。实验要求我们实验一个sys_taskinfo系统调用，来获取当前任务的任务信息。所以根据以前的操作系统知识，很自然的就能想到应该在进程控制块中加入我们需要收集的信息。我在实现的时候存在数据冗余问题，我先在TaskManagerInner中加入了一个任务信息Taskinfo字段，又加入了一个任务创建时间create_time字段，实际上Taskinfo.status和Taskinfo.time是多存的不必要的信息，因此我在后面的章节之后进行了重构，只加入了create_time和syscall_times两个字段。
+ 在本章节中，内核加入了虚拟空间机制，让进程的实现更加完整。实验要求我们移植get_time和taskinfo系统调用，并增加sys_mmap和sys_munmap系统调用。由于rcore的实现是双页表，内核页表和进程页表是分开的，进行系统调用的时候会切换页表，移植操作就需要进行地址转换拿到进程空间的地址来进行写入。内存映射的系统调用实现根据提示能做出来比较简单的实现便能通过测试，但是实际在取消内存映射的时候，可能需要对内存区域进行分割和合并的操作，例如可能会涉及内存管理算法什么的，似乎题目没做要求，我还没有实现，做完后续实验填坑吧。
+ 在本章节中，内核实现了进程机制，使得能够进程能够创建子进程(fork)、用新的程序覆盖已有程序内容(exec)。实验要求我们移植向前的代码并实现Spawn系统调用(fork+exec)，再实现stride调度算法。
+
-
-
-
- 在完成 这样的渐进式布置, 有助于理解操作系统设计的思路，对于我个人而言， 前2章将用户程序链接到内核反而是最困难的，也是平时学习中不容易注意到的知识点。 按照指导书进行环境配置对于基础的代码运行是没有问题，但我发现自己按照指导书操作后无法进行 安装完整的 本次作业需要实现 相比于之前的实现, 唯一的变化就是系统调用函数中传递的指针不能直接使用, 因为内核页表与用户页表是不同的。 通过软件的实现来转换地址 本项目中, 这两个系统调用仅用于申请内存。在实际上, 思路和 实现硬链接的系统调用: 可以看到, 尽管思路清晰, 但实际的视线还是较为繁琐, 主要体现在各个数据块的查找, 判断其有效性等, 以下是具体的视线思路 此处对任务书中的算法进行进一步补充
-
- 2023开源操作系统训练营第二阶段总结报告-ToniXWD
-
-
-
-
-
-
-
-
-
-
-
-
- 1 整体总结
Rustlings后，终于能亲自上手把玩操作系统了。rCore的每一个branch实际上可以看做是对一个初具框架项目的不断更新和迭代。ch1是在裸机上部署一个hello world, ch2是引入了特权级, ch3实现分时多任务系统, ch4引入了虚拟内存和页表, ch5引入了进程的概念并提供了相关系统调用和调度算法支持, ch6添加了简易文件系统, ch7添加了管道这一古老的ipc方法, ch8引入了线程的概念并加入了与线程同步相关的资源:锁, 信号量和条件变量。lab的难度整体上不算太高, 但需要注意细节, 另外兼容前一个章节的代码确实会带来一些压力, 比如lab5时, 我卡住了很久, 最后才发现需要重新实现sys_get_time, 希望老师们能在以后的课程中考虑到这个问题2 lab 通关记录
2.1 ch0-环境配置
gdb调试, 经过总结后在此处给出我的2种解决方案:方案1: 安装完整的
riscv-gnu-toolchainriscv-gnu-toolchain流程如下, 次方法费时较长, 且占据空间较大, 更推荐第二种方法。
-
-1
$ sudo apt-get install autoconf automake autotools-dev curl libmpc-dev libmpfr-dev libgmp-dev gawk build-essential bison flex texinfo gperf libtool patchutils bc zlib1g-dev libexpat-dev
riscv-gnu-toolchain 1
$ git clone --recursive https://github.com/riscv/riscv-gnu-toolchain
-1
2
3$ cd riscv-gnu-toolchain
$ ./configure --prefix=/usr/local
$ sudo make方案2: 编译安装
riscv64-unknown-elf-gdb1
$ sudo apt-get install libncurses5-dev python2 python2-dev texinfo libreadline-dev
gdb源码
此处我选择gdb-13.1, 该版本在wsl2 Ubuntu22.04上使用正常。 1
2
3
4# 推荐清华源下载
wget https://mirrors.tuna.tsinghua.edu.cn/gnu/gdb/gdb-13.1.tar.xz
# 解压
tar -xvf gdb-13.1.tar.x
只需要指定编译安装riscv64-unknown-elf并配置相关参数。
-
-1
2
3
4
5$ cd gdb-13.1
$ mkdir build && cd build
$ ../configure --prefix=/your_path --target=riscv64-unknown-elf --enable-tui=yes
$ make -j$(nproc)
$ sudo make install2.2 ch3-lab1
sys_task_info这一系统调用以统计task信息。总体思路
-
-task.rs中的TaskControlBlock结构体增加了sys_call_times数组, 用于记录当前task中各个系统调用的次数, 以及sys_call_begin,记录任务创建的起始时间1
2
3
4
5
6
7
8pub struct TaskControlBlockInner {
...
/// syscall time count
pub sys_call_times: [u32; MAX_SYSCALL_NUM],
/// begen time
pub sys_call_begin: usize,
...
}TASK_MANAGER中当前任务current_task对应的TaskControlBlock结构体的系统调用记录自增sys_call_begin = 0, 说明这个task是第一次被调用, 需要将sys_call_begin设置为当前时间TaskManager实现get_sys_call_times方法, 获取当前任务current_task对应的TaskControlBlock结构体的系统调用数组的拷贝process.rs的sys_task_info, 调用get_sys_call_times和get_time_ms获取TaskInfo结构体的syscall_times和time部分, status部分设为Running2.3 ch4-lab2
2.3.1 重新实现
sys_get_time 和 sys_task_info思路
> 参考`translated_byte_buffer`实现`translated_struct_ptr`
-`translated_byte_buffer`将一个指向`u8`数组的指针按照指定的页表获取其物理地址, 我们不需要获取数组的长度, 只需要通过指定的泛型告知`PhysAddr`的`get_mut`方法需要转化的类型即可。2.3.2
mmap 和 munmap 匿名映射mmap 系统调用是用来将一个文件或者其他对象映射进调用进程的地址空间的。它通常映射到进程的用户空间，使得进程能够像访问普通内存一样访问文件的内容, 减少IO次数。mmap 实现思路：
-
-task的内存地址空间
可以用TaskManagerInner的current_task找到当前的task序号, 再在tasks中找到对应的memory_setmemory_set上申请内存
需要注意的是, 分配内存页需要调用frame_alloc, 为了内存页的自动回收, 还需要将其加入一个集合类型中, 这里我为MemorySet新增了成员map_tree: BTreeMap<VirtPageNum, FrameTracker>用以接受mmap新分配的FrameTracker:
-
-1
2
3
4
5pub struct MemorySet {
page_table: PageTable,
areas: Vec<MapArea>,
map_tree: BTreeMap<VirtPageNum, FrameTracker>,
}munmap 实现思路mmap类似
-
-page_table的unmap方法删除映射map_tree的remove方法移除FrameTracker使其能被FRAME_ALLOCATOR回收易错点
-
-PageTableEntry的is_valid方法判断转换后页表项的有效性mmap使要判断地址是否对齐2.4 ch5-lab3
2.4.1 实现
sys_spawn系统调用sys_spawn系统调用从效果上就是fork+exec, 区别在于既然马上要exec, 就没有必要负责父进程的地址空间了, 毕竟马上就要被覆盖掉, 因此, 思路如下:
-
-exec一样, 将地址通过task处获取的页表进行转化得到有效的字符串get_app_data_by_name直接获取文件的u8数组表示的elf数据elf数据传入TaskControlBlock::new获取一个新的任务控制块task加入任务列表2.4.2 实现
stride 调度算法stride本质上就是综合了任务优先级程序后的任务运行时间的反映, 每次选择stride值最低的任务运行,一定程度上实现了公平的调度。实现思路
config.rs中添加常量BigStrideTaskControlBlockInner中新增如下成员: 1
2
3
4
5
6
7
8pub struct TaskControlBlockInner {
...
/// 当前 stride
pub cur_stride: usize,
/// 优先级等级
pub pro_lev: usize,
...
}stride值最低的任务运行
阅读代码可知, run_tasks方法每次都是调用TaskManager::fetch方法来获取下一个运行任务, 因此只需要修改fetch方法来实现我们的调度算法。
由于TaskManager使用ready_queue: VecDeque<Arc<TaskControlBlock>>来存放TaskControlBlock, 每次调用fetch时，对ready_queue按照stride进行排序, 然后pop_front即可stride
使其cur_stride变量自增BIG_STRIDE / var.pro_lev即可2.5 ch6-lab4
2.5.1 硬链接简介
linkat和unlinkat
硬链接: 本质上就是不同的目录项指向了同一个innode, 因此实现linkat和unlinkat的流程如下:
-
-linkat
-
-innode号innode号innode的引用计数自增1
-
-unlinkat
-
-innode号innode的引用计数自减1innode的引用计数变成0, 将其以及指向的数据块释放2.5.2 实现思路
-
-linkat
-
-DiskInode结构体, 添加引用计数成员refcont
-需要注意的是, 1
2
3
4
5
6pub struct DiskInode {
...
pub direct: [u32; INODE_DIRECT_COUNT],
pub refcont: u32, // 新增这个变量后需要将 INODE_DIRECT_COUNT - 1
...
}DiskInode需要匹配其在block中的大小, 因此我们添加了一个变量refcont, 需要将将 INODE_DIRECT_COUNT - 1以保证其在block中的大小不变translated_str获取实际的_old_name和_new_nameROOT_INODE中调用read_disk_inode查询old_name的inode序号inode_idROOT_INODE中调用modify_disk_inode写入新的目录项
需要注意计算新的size并调用increase_size分盘空间inode_id调用get_disk_inode_pos得到具体的inode位置, 将其引用计数自增block_cache_sync_all同步更新
-
-unlinkat
-
-translated_str获取实际的_name和ROOT_INODE中调用read_disk_inode查询_name的inode序号inode_id, 注意需要判断其是否存在ROOT_INODE中调用modify_disk_inode删除找到的目录项
注意此处的删除, 我的实现思路是
-
-size自减size自减inode_id调用get_disk_inode_pos得到具体的inode位置, 将其引用计数自减innode引用计数达到了0, 需要释放其空间
调用clear_size获取其的每一个数据block, 并调用EasyFileSystem::dealloc_data进行清理2.6 ch8-lab5
2.6.1 死锁检测算法进一步介绍
-
-Available[m]: 其下标对应的资源是最具体的资源, 比如具体是哪一把锁, 哪一个信号量
可知, 进程是最基础的资源管理单位, 因此这一统计资源应该放在ProcessControlBlockInner中Allocation[n][m]: 每个具体资源已分配给每个线程的资源数, 具体而言就是lock了但还没unlock时需要记录资源的使用数量
这个资源仍然可通过ProcessControlBlockInner来管理, 但是这样的话每个线程创建和操作相应资源时, 还需要在访问一次进程控制块, 因此可以将其托管给线程控制块TaskControlBlockInnerNeed[n][m]: 表示每个线程还需要的各类资源数量, 具体而言, 在lock前需要先登记需求, 将对应的资源自增, 在lock后则需要撤销这次登记
同Allocation[n][m]类似, 托管给线程控制块TaskControlBlockInner管理是更容易的实现2.6.2 实现思路
-
-ProcessControlBlockInner结构体, 添加Available[m]
- 注意这里我使用2个1
2
3
4
5
6
7
8
9pub struct ProcessControlBlockInner {
...
/// mutex的Available[m]
pub m_available: Vec<usize>,
/// 信号量的Available[m]
pub s_available: Vec<usize>,
/// 是否使用死锁检测
pub use_dead_lock: bool,
}Available[m]变量s_available和m_available, 分别控制信号量和锁TaskControlBlockInner结构体, 添加Allocation[m]和Need[m]
- 由于是将其托管到1
2
3
4
5
6
7
8
9
10pub struct TaskControlBlockInner {
/// mutex的Allocation[m]
pub m_allocation: Vec<usize>,
/// 信号量的Allocation[m]
pub s_allocation: Vec<usize>,
/// mutex的Need[m]
pub m_need: Vec<usize>,
/// 信号量的Need[m]
pub s_need: Vec<usize>,
}TaskControlBlockInner管理, 因此Allocation[m]和Need[m]退化为了一维数组, 同时将信号量和锁分开管理sys_mutex_create和sys_semaphore_create
拿到对应资源的序号id后, 需要更新m_available和s_available, 注意的是m_available只需要自增1, 而s_available需要自增信号量分配的具体值sys_mutex_lock和sys_semaphore_down
-
-s_need或m_need进行自增s_need或m_need进行自减以撤销登记, 同时将m_available或s_available自减以标识资源被占用, 将m_allocation或s_allocation自增以标识自身对资源的占用sys_mutex_unlock和sys_semaphore_up
-
-s_available或m_available自增以归还资源, 将m_allocation或s_allocation自减以标识自身对资源的释放2.6.3 易错点
-
-
-
- m_available统计资源进行访问时, 要同步更新所有TaskControlBlockInner中的m_allocation和m_need的数组长度以防止后续数组访问越界, 访问s_available时同理inner_exclusive_access方法获取process_inner或task_inner时, 要注意此前是否已经获取过相应资源, 尤其是在多层函数调用时, 需要手动drop掉以上变量sys_get_time,一定要实现sys_get_time!!!
在完成Rustlings后，终于能亲自上手把玩操作系统了。rCore的每一个branch实际上可以看做是对一个初具框架项目的不断更新和迭代。ch1是在裸机上部署一个hello world, ch2是引入了特权级, ch3实现分时多任务系统, ch4引入了虚拟内存和页表, ch5引入了进程的概念并提供了相关系统调用和调度算法支持, ch6添加了简易文件系统, ch7添加了管道这一古老的ipc方法, ch8引入了线程的概念并加入了与线程同步相关的资源:锁, 信号量和条件变量。
这样的渐进式布置, 有助于理解操作系统设计的思路，对于我个人而言， 前2章将用户程序链接到内核反而是最困难的，也是平时学习中不容易注意到的知识点。
+lab的难度整体上不算太高, 但需要注意细节, 另外兼容前一个章节的代码确实会带来一些压力, 比如lab5时, 我卡住了很久, 最后才发现需要重新实现sys_get_time, 希望老师们能在以后的课程中考虑到这个问题
按照指导书进行环境配置对于基础的代码运行是没有问题，但我发现自己按照指导书操作后无法进行gdb调试, 经过总结后在此处给出我的2种解决方案:
riscv-gnu-toolchain安装完整的riscv-gnu-toolchain流程如下, 次方法费时较长, 且占据空间较大, 更推荐第二种方法。
1 | $ sudo apt-get install autoconf automake autotools-dev curl libmpc-dev libmpfr-dev libgmp-dev gawk build-essential bison flex texinfo gperf libtool patchutils bc zlib1g-dev libexpat-dev |
riscv-gnu-toolchain 1 | $ git clone --recursive https://github.com/riscv/riscv-gnu-toolchain |
1 | $ cd riscv-gnu-toolchain |
riscv64-unknown-elf-gdb1 | $ sudo apt-get install libncurses5-dev python2 python2-dev texinfo libreadline-dev |
gdb源码wsl2 Ubuntu22.04上使用正常。 1 | # 推荐清华源下载 |
riscv64-unknown-elf并配置相关参数。 1 | $ cd gdb-13.1 |
本次作业需要实现sys_task_info这一系统调用以统计task信息。
task.rs中的TaskControlBlock结构体增加了sys_call_times数组, 用于记录当前task中各个系统调用的次数, 以及sys_call_begin,记录任务创建的起始时间1 | pub struct TaskControlBlockInner { |
TASK_MANAGER中当前任务current_task对应的TaskControlBlock结构体的系统调用记录自增sys_call_begin = 0, 说明这个task是第一次被调用, 需要将sys_call_begin设置为当前时间TaskManager实现get_sys_call_times方法, 获取当前任务current_task对应的TaskControlBlock结构体的系统调用数组的拷贝process.rs的sys_task_info, 调用get_sys_call_times和get_time_ms获取TaskInfo结构体的syscall_times和time部分, status部分设为Runningsys_get_time 和 sys_task_info相比于之前的实现, 唯一的变化就是系统调用函数中传递的指针不能直接使用, 因为内核页表与用户页表是不同的。
+通过软件的实现来转换地址
+> 参考`translated_byte_buffer`实现`translated_struct_ptr`
+`translated_byte_buffer`将一个指向`u8`数组的指针按照指定的页表获取其物理地址, 我们不需要获取数组的长度, 只需要通过指定的泛型告知`PhysAddr`的`get_mut`方法需要转化的类型即可。mmap 和 munmap 匿名映射 本项目中, 这两个系统调用仅用于申请内存。在实际上, mmap 系统调用是用来将一个文件或者其他对象映射进调用进程的地址空间的。它通常映射到进程的用户空间，使得进程能够像访问普通内存一样访问文件的内容, 减少IO次数。
mmap 实现思路：task的内存地址空间TaskManagerInner的current_task找到当前的task序号, 再在tasks中找到对应的memory_setmemory_set上申请内存frame_alloc, 为了内存页的自动回收, 还需要将其加入一个集合类型中, 这里我为MemorySet新增了成员map_tree: BTreeMap<VirtPageNum, FrameTracker>用以接受mmap新分配的FrameTracker:1 | pub struct MemorySet { |
munmap 实现思路思路和mmap类似
page_table的unmap方法删除映射map_tree的remove方法移除FrameTracker使其能被FRAME_ALLOCATOR回收PageTableEntry的is_valid方法判断转换后页表项的有效性mmap使要判断地址是否对齐sys_spawn系统调用sys_spawn系统调用从效果上就是fork+exec, 区别在于既然马上要exec, 就没有必要负责父进程的地址空间了, 毕竟马上就要被覆盖掉, 因此, 思路如下:
exec一样, 将地址通过task处获取的页表进行转化得到有效的字符串get_app_data_by_name直接获取文件的u8数组表示的elf数据elf数据传入TaskControlBlock::new获取一个新的任务控制块task加入任务列表stride 调度算法stride本质上就是综合了任务优先级程序后的任务运行时间的反映, 每次选择stride值最低的任务运行,一定程度上实现了公平的调度。config.rs中添加常量BigStrideTaskControlBlockInner中新增如下成员: 1 | pub struct TaskControlBlockInner { |
stride值最低的任务运行run_tasks方法每次都是调用TaskManager::fetch方法来获取下一个运行任务, 因此只需要修改fetch方法来实现我们的调度算法。TaskManager使用ready_queue: VecDeque<Arc<TaskControlBlock>>来存放TaskControlBlock, 每次调用fetch时，对ready_queue按照stride进行排序, 然后pop_front即可stridecur_stride变量自增BIG_STRIDE / var.pro_lev即可实现硬链接的系统调用: linkat和unlinkat
硬链接: 本质上就是不同的目录项指向了同一个innode, 因此实现linkat和unlinkat的流程如下:
linkatinnode号innode号innode的引用计数自增1unlinkatinnode号innode的引用计数自减1innode的引用计数变成0, 将其以及指向的数据块释放可以看到, 尽管思路清晰, 但实际的视线还是较为繁琐, 主要体现在各个数据块的查找, 判断其有效性等, 以下是具体的视线思路
+linkatDiskInode结构体, 添加引用计数成员refcont1 | pub struct DiskInode { |
DiskInode需要匹配其在block中的大小, 因此我们添加了一个变量refcont, 需要将将 INODE_DIRECT_COUNT - 1以保证其在block中的大小不变translated_str获取实际的_old_name和_new_nameROOT_INODE中调用read_disk_inode查询old_name的inode序号inode_idROOT_INODE中调用modify_disk_inode写入新的目录项size并调用increase_size分盘空间inode_id调用get_disk_inode_pos得到具体的inode位置, 将其引用计数自增block_cache_sync_all同步更新unlinkattranslated_str获取实际的_name和ROOT_INODE中调用read_disk_inode查询_name的inode序号inode_id, 注意需要判断其是否存在ROOT_INODE中调用modify_disk_inode删除找到的目录项size自减size自减inode_id调用get_disk_inode_pos得到具体的inode位置, 将其引用计数自减innode引用计数达到了0, 需要释放其空间clear_size获取其的每一个数据block, 并调用EasyFileSystem::dealloc_data进行清理此处对任务书中的算法进行进一步补充
+Available[m]: 其下标对应的资源是最具体的资源, 比如具体是哪一把锁, 哪一个信号量ProcessControlBlockInner中Allocation[n][m]: 每个具体资源已分配给每个线程的资源数, 具体而言就是lock了但还没unlock时需要记录资源的使用数量ProcessControlBlockInner来管理, 但是这样的话每个线程创建和操作相应资源时, 还需要在访问一次进程控制块, 因此可以将其托管给线程控制块TaskControlBlockInnerNeed[n][m]: 表示每个线程还需要的各类资源数量, 具体而言, 在lock前需要先登记需求, 将对应的资源自增, 在lock后则需要撤销这次登记Allocation[n][m]类似, 托管给线程控制块TaskControlBlockInner管理是更容易的实现ProcessControlBlockInner结构体, 添加Available[m]1 | pub struct ProcessControlBlockInner { |
Available[m]变量s_available和m_available, 分别控制信号量和锁TaskControlBlockInner结构体, 添加Allocation[m]和Need[m]1 | pub struct TaskControlBlockInner { |
TaskControlBlockInner管理, 因此Allocation[m]和Need[m]退化为了一维数组, 同时将信号量和锁分开管理sys_mutex_create和sys_semaphore_createid后, 需要更新m_available和s_available, 注意的是m_available只需要自增1, 而s_available需要自增信号量分配的具体值sys_mutex_lock和sys_semaphore_downs_need或m_need进行自增s_need或m_need进行自减以撤销登记, 同时将m_available或s_available自减以标识资源被占用, 将m_allocation或s_allocation自增以标识自身对资源的占用sys_mutex_unlock和sys_semaphore_ups_available或m_available自增以归还资源, 将m_allocation或s_allocation自减以标识自身对资源的释放m_available统计资源进行访问时, 要同步更新所有TaskControlBlockInner中的m_allocation和m_need的数组长度以防止后续数组访问越界, 访问s_available时同理inner_exclusive_access方法获取process_inner或task_inner时, 要注意此前是否已经获取过相应资源, 尤其是在多层函数调用时, 需要手动drop掉以上变量sys_get_time,一定要实现sys_get_time!!!第三阶段我参加的是向勇老师的项目6：异步操作系统的实现。
+总的来说，6周的项目实训过程中，读了很多代码和文档，做了很多事情，学到了很多的东西。
+在参加训练营之前，我对异步的了解其实也就是局限于说我们IO要异步，让出控制权，仅此而已。
+但是在训练营中，我真正的接触到了何谓真正的异步，以及如何去实现它，受益匪浅。
+同时我也将ArceOS的宏内核版本，将其进行了异步化，使整个内核都使用rust的async和await异步编程实现。
+同时它也是无栈协程的切换方式，且对协程采用多栈复用的抢占。
+在成果上，实现了对ArceOS家族系的Starry的异步化改造，使用async和await等rust提供的异步编程编写内核，已实现核心主体框架；同时对通用操作系统内核下协程的不合理性做调整，实现内核栈池，通过少量堆栈的复用实现对诸如键盘输入等高优先协程处理的抢占机制。
+为后来者留下的东西，首先是代码产出：有充足的代码仓库参考，我将各个小步骤的代码都保存了下来。从原始版本 -> task实现 -> 同步无栈协程与显式执行流 -> 异步无栈协程 -> 多栈复用版本。
+同时留下了若干个人的文档心得：考虑到训练营很多同学对从同步到异步的过程一头雾水，其实我本人最开始也是这样的，我个人认为更好的办法是看别人的代码，看看别人是怎么实现了，跟着别人学，先模仿，再谈能不能超越，因此留下文档如下：
+当然，更多的中间过程结果在项目六，向老师的文档中有所记录，这里不再列出。
+总的来说，第三阶段也算有一定的产出，这么长时间也算没白干，身为一个寄算机人，一切都要落实到代码产出上，光写文档吹牛逼不是一个合格的程序猿。
+对我这个异步小白来说，理解和实现异步，再到利用异步的过程，是比较复杂且困难的，而且所面对的是如此大的一个内核，其藕断丝连的耦合性会对改造造成相当大的麻烦。尤其是我们对整个调度和进程管理的部分进行一次彻底的重构，这种挑战相当之大。
+但是挑战之大，也是挺过来了，在改造整体框架下，大概前前后后推倒重来了十多次，这也是为什么我那么注重保存每一个小步骤的代码。
+总的来说，训练营中我给自己列了一个很高的挑战，也尽力的去完成它了，最后的结果我个人是非常满意的，达到了自己对自己的要求。
+ + +真是一段很长的旅程啊，怎么说呢，这一阶段的任务我基本上都是“挣扎”着完成的，一开始感觉以我对 Rust 和 OS 的理解，应该此阶段的任务不会非常困难。后来发现还得是“纸上得来终觉浅，绝知此事要躬行”，有些东西在课上学习理论知识和实际使用代码进行实现完全是不一样的感觉，而且怎么说呢，Rust 的运用程度实际上对编写操作系统的帮助也不是特别大，就好像你要和亚里士多德探讨哲学问题，重点是这个哲学问题，而不是古希腊语，当然你得先对古希腊语有一个大致的了解，但是古希腊语本身对理解这个哲学问题是没有什么帮助的。
-反正总之由于种种原因，我感觉我在这方面的经验根本就是 0，导致本阶段的任务超出截止时间一周差不多才完成。
-但是怎么说呢，就好比是 DND 里面的等级系统一样，在等级为 1 的情况下，升到 2 级所需要的经验值是很少的，所以这个训练营给我的提升感觉也特别大（OS 子职等级），了解到了很多之前根本没有机会接触的知识领域，最重要的，更是加深了我对 os 的理解。
-我在第一阶段的总结之中也提到了我非常崇拜 Linux，现在感觉我离他好像又进一步了，感到非常开心！
-在写这篇博客时，本人东北大学大三在读，前两年东学西学，Rust 就是之一，说实话，在本学期开始时，我实在找不到什么东西来做，准备先买一本《趣读 Linux 源码》来看，感谢我学弟翊嘉，是他给我推荐了这个操作系统训练营，这样直接上手操作系统的效果比看书要好太多了，真的十分感谢！
-我对 Rust 的理解还是比较少，future、unsafe 的内容更是知之甚少，所以大佬求带！看到我这篇总结报告之中有什么不足也请指出！
-最近在看 Linus 的自传，他在里面讲了一段关于 OS 的话感觉说得特别好：
---计算机上的所有功能要起作用，都得以操作系统为基础。于是，创造一个操作系统就成了终极挑战。你创造操作系统的时候，相当于给所有在这部电脑上跑的程序创造了一个全新的生存环境—从根本上说，其实就是在制定这个世界的规则：什么事可以接受、可以做，什么事不可以接受、不可以做。其实所有的程序都是在制定规则，只不过操作系统制定的是最根本的规则。创造一个操作系统，就相当于自己创造的一方土地制定宪法，而在电脑上跑的程序则相当于各式各样的普通法律。
-
这段话形象地表达了操作系统的功能、作用、以及它对上层应用程序强大的控制能力，但是实际上感觉在实现了一些东西之后，好像也不完全是这样。
-原来就是认为是下面这个层级关系：
-但是在使用 RISC-V 实际上应该是这样的！
-实际上操作系统也要向下请求 sbi 提供的功能！在本次训练营之中一个比较常用的功能——往屏幕上输出字符就是通过 sbi 完成的。实际上完全不止于此，SBI 还会在计算机启动的时候进行它所负责的环境初始化工作，并将计算机控制权移交给内核，操作系统的关闭也是由 SBI 控制的。
-从 RISC-V 特权级架构的视角来看，我们编写的 OS 内核位于 Supervisor 特权级，而 RustSBI 位于 Machine 特权级，也是最高的特权级。
-说实话，我对 SBI 的理解就到此为止了，在代码之中，很贴心地向我们提供了 SBI 服务调用的接口，我们直接使用就可以了。
-这部分我感觉还不是很清楚的内容：
SBI 的内容我感觉真的后续还有必要继续学习一下。
在本阶段的相关代码项目之中，除了一些关键的处理 Trap 和上下文切换的逻辑是使用汇编进行编写的之外，其他都是使用 Rust 编写的、和普通的用户应用程序并没有什么不同。
-在实现了地址空间之后，基本上就完全停留在逻辑上的开发了，不再关心操作系统的实现细节，实际上我在实现了进程和文件系统的相关功能之后回头一看都感觉地址空间之中的一些实现细节都开始遗忘了。
-这部分我感觉还不是很清楚的内容：
Rust 编译器是如何将这个汇编代码和 Rust 代码链接在一起的？
而且在 Rust 之中是如何调用在汇编代码之中定义的过程的？
而且我发现真的一个应用程序实际上非常简单，就是一堆指令，pc 拿到之后一条条执行，然后会有一个跳转指令跳转到另外一条指令进行执行，然后指令的操作数都是从寄存器拿出来的，线程或者进程实际上就是一个包装了指令流的上下文，在里面进行了一些簿记工作，记录了当前指令进行到了哪里，然后一些相关寄存器的状态。
- - -感谢老师和主教们提供的这么一次宝贵的学习操作系统的课程，不管是老师们上课时的专业程度，还是文档的详细度，或是练习的代码，都体现出了老师们对于这门课付出的大量的时间和心血。在第一阶段的学习中，我了解和熟悉了Rust语言的使用方法，并在rustlings中尝试解决各种问题。当然，rust语言也并没有那么容易上手，加上时间有限，在学习第一阶段时候我对rust语言本身还是只有一个概念的雏形，有些rust的语法特性由于缺乏实践没有真正掌握。当然，在第二阶段的学习中，我开始真正尝试使用rust实现系统调用，同时努力学习吸收老师们的代码和思路，不仅能够更加熟练的使用rust语言，还对操作系统有了更清晰的概念。
+ + + + + +
-
-
-
-
-
- rcore2023A-PeizhongQiu
-
-
-
-
我是在一年前关注到“开源操作系统训练营”这个活动的，但是苦于那时在进行本科毕业设计工作，没有抽出时间来参加。在那时，我就已经对系统软件、 Rust很感兴趣了，因此本科毕业设计做的也是 OS 相关的工作。如今在研一，课业之外有了一部分时间，想用来提升自身对 OS 前沿的认识，同时积累一些工程经验，于是便参加了今年的开源 OS 训练营。
-Rust 是一门比较新的系统级编程语言，我最早听说 Rust 是在一次高中同学聚会上。那时候，我的一位高中同学所在的大学（不是清华）已经使用 Rust 来布置一些课程的大作业，而我所在的大学还没有涉及 Rust 的课程。
-我对 Rust 最深刻的印象是“内存安全”和“系统级编程语言”，但之后的很长一段时间里，我都没有去更深入地了解 Rust 了，原因很简单：没有时间、对课程也没什么帮助。
-后来，做毕业设计的时候，导师偶尔会提到一些清华大学陈渝老师组的一些 OS 方面的前沿研究工作，比如押宝 Rust、组件化 OS 之类的。因此，我对 Rust 的认识也在发生转变。实际上，OS 发展中一个重要的影响因素就是系统级编程语言，而 Rust 作为一门比较新的系统级编程语言，未来势必影响 OS 的发展。
-经过了两个阶段的学习，我对 Rust 的特点有了更深入的认识：Rust 解决的内存安全问题的方法是将相当一部分内存安全检查放到了编译时，同时又提供了 unsafe 块赋予内核设计者操作底层硬件的能力。换言之，我们只需要保证将尽可能少的代码放在 unsafe 块，并保证这一小部分代码是内存安全的，那么经过 rustc 编译后的内核就是内存安全的。
第一次与 rCore 结缘是在第七届“龙芯杯”大赛中，只不过那时遇到的是 rCore 的前身 uCore。
---rCore 是 uCore 的 Rust 重构版本，而 uCore 参考了 XV6 的实现。从指令架构上来看，XV6 支持的是 x86，一种广泛使用的 CISC，但由于其闭源性、复杂性已经逐渐被教学所抛弃。uCore、rCore 面向的是以 RISCV 为代表的 RISC。RISC 最早提出是为了解决 CISC 指令间相关性难以判断的问题，两条 RISC 指令之间很容易判断相关性，从而实现流水线的微架构设计。
-
此次参加开源 OS 训练营，是我第一次学习 rCore。在学习过程中，我体会到了 rCore 是如何利用 Rust 语言的机制（特点）进行编写的。接下来我将举例总结。
-cargo：Rust 的包管理、构建工具相比于 C 语言等传统的系统级编程语言，Rust 提供了包管理和构建工具 cargo，好处是：
可以方便地引入一些库，为编写内核提供便利，无需重复造论子
- 比如说在 ch3 中出现了一个 heap_alloc.rs 文件，他在里面创建了一个静态的 HEAP_ALLOCATOR，并使用 #[global_allocator] 进行了标记。后来在 ch4 的文档里我才理解它是用来进行（物理）堆内存分配的分配器，这样就能在内核里使用堆上数据了。而该分配器的具体实现则无需我们操心了，因为它是由一个名为 buddy_system_allocator 的 crate 提供的（结果上 crates.io 一查，是由 rcore-os 组织维护的一个库）。
构建过程更加简单
理论上来说，构建一个 Rust 项目只需要 cargo build 就够了，但 rCore 实验还有其他需求，因此框架里使用了 Makefile。
rCore 的内存管理系统巧妙地利用了 Rust 的所有权和声明周期机制。当申请了一个物理页时，分配函数 frame_alloc() 直接将物理页描述符 FrameTracker 的所有权返回，而这些页描述符的所有权直接被申请物理页的变量所拥有（如 PageTable 或 MapArea）。当这些变量的声明周期结束时，他们所持有的 FrameTracker 的生命周期也将结束，而 rCore 为 FrameTracker 实现了 Drop trait，将在它们生命周期结束时“自动”回收物理页。
我是在一年前关注到“开源操作系统训练营”这个活动的，但是苦于那时在进行本科毕业设计工作，没有抽出时间来参加。在那时，我就已经对系统软件、 Rust很感兴趣了，因此本科毕业设计做的也是 OS 相关的工作。如今在研一，课业之外有了一部分时间，想用来提升自身对 OS 前沿的认识，同时积累一些工程经验，于是便参加了今年的开源 OS 训练营。
+Rust 是一门比较新的系统级编程语言，我最早听说 Rust 是在一次高中同学聚会上。那时候，我的一位高中同学所在的大学（不是清华）已经使用 Rust 来布置一些课程的大作业，而我所在的大学还没有涉及 Rust 的课程。
+我对 Rust 最深刻的印象是“内存安全”和“系统级编程语言”，但之后的很长一段时间里，我都没有去更深入地了解 Rust 了，原因很简单：没有时间、对课程也没什么帮助。
+后来，做毕业设计的时候，导师偶尔会提到一些清华大学陈渝老师组的一些 OS 方面的前沿研究工作，比如押宝 Rust、组件化 OS 之类的。因此，我对 Rust 的认识也在发生转变。实际上，OS 发展中一个重要的影响因素就是系统级编程语言，而 Rust 作为一门比较新的系统级编程语言，未来势必影响 OS 的发展。
+经过了两个阶段的学习，我对 Rust 的特点有了更深入的认识：Rust 解决的内存安全问题的方法是将相当一部分内存安全检查放到了编译时，同时又提供了 unsafe 块赋予内核设计者操作底层硬件的能力。换言之，我们只需要保证将尽可能少的代码放在 unsafe 块，并保证这一小部分代码是内存安全的，那么经过 rustc 编译后的内核就是内存安全的。
第一次与 rCore 结缘是在第七届“龙芯杯”大赛中，只不过那时遇到的是 rCore 的前身 uCore。
+++rCore 是 uCore 的 Rust 重构版本，而 uCore 参考了 XV6 的实现。从指令架构上来看，XV6 支持的是 x86，一种广泛使用的 CISC，但由于其闭源性、复杂性已经逐渐被教学所抛弃。uCore、rCore 面向的是以 RISCV 为代表的 RISC。RISC 最早提出是为了解决 CISC 指令间相关性难以判断的问题，两条 RISC 指令之间很容易判断相关性，从而实现流水线的微架构设计。
+
此次参加开源 OS 训练营，是我第一次学习 rCore。在学习过程中，我体会到了 rCore 是如何利用 Rust 语言的机制（特点）进行编写的。接下来我将举例总结。
+cargo：Rust 的包管理、构建工具相比于 C 语言等传统的系统级编程语言，Rust 提供了包管理和构建工具 cargo，好处是：
可以方便地引入一些库，为编写内核提供便利，无需重复造论子
+ 比如说在 ch3 中出现了一个 heap_alloc.rs 文件，他在里面创建了一个静态的 HEAP_ALLOCATOR，并使用 #[global_allocator] 进行了标记。后来在 ch4 的文档里我才理解它是用来进行（物理）堆内存分配的分配器，这样就能在内核里使用堆上数据了。而该分配器的具体实现则无需我们操心了，因为它是由一个名为 buddy_system_allocator 的 crate 提供的（结果上 crates.io 一查，是由 rcore-os 组织维护的一个库）。
构建过程更加简单
理论上来说，构建一个 Rust 项目只需要 cargo build 就够了，但 rCore 实验还有其他需求，因此框架里使用了 Makefile。
rCore 的内存管理系统巧妙地利用了 Rust 的所有权和声明周期机制。当申请了一个物理页时，分配函数 frame_alloc() 直接将物理页描述符 FrameTracker 的所有权返回，而这些页描述符的所有权直接被申请物理页的变量所拥有（如 PageTable 或 MapArea）。当这些变量的声明周期结束时，他们所持有的 FrameTracker 的生命周期也将结束，而 rCore 为 FrameTracker 实现了 Drop trait，将在它们生命周期结束时“自动”回收物理页。