title: 2025春夏开源操作系统训练营总结-mf1bzz
date: 2025-05-06 12:45:01
categories:
- 2025春夏季开源操作系统训练营
tags:
- author: MF-B
- repo: https://github.com/MF-B/Note
- blog: https://blog.mf1bzz.cn

OS Camp Stage 1

感想

一阶段是Rust编程
Rust有很好的官方教程,也有很多第三方资料

我是直接开始做rustling来学习的
遇到不懂的就去翻手册,我看过的参考资料都记录到了下面

OS Camp Stage 2

感想

二阶段是rCore学习
rCore一共九章,篇幅很大,前前后后大概花了20天的时间,整个过程还是非常有意思的

二阶段对我个人的提升很大,由于之前没有学过操作系统,rCore的学习让我理解操作系统是什么,之前一些对计算机的模糊概念也渐渐清晰了起来,也顺便提高了我的Rust编程能力

看的比较多的就是Risc-V的参考手册了

OS Camp Stage 3

感想

虽然做二阶段的时候看过一些ArceOS的代码,但是并没有看懂,不过经过第三阶段的学习之后,我逐渐了解到了ArceOS的组织方式,相比于rcore,拓展性是肉眼可见的提高了,也更易于维护.

总结

参加训练营让我学到了很多,但也暴露了我的很多问题,我意识到我的算法能力太过于薄弱,学完学校教的数据结构之后就几乎没有怎么碰过算法了,做三阶段挑战题时也是花了一整天也没有达到最高分数;
不过不暴露缺点的话,也谈不上要改进了.

title: 2024秋冬开源操作系统第一阶段总结-yqthz
date: 2024-11-06 20:42:18
categories:

• report
  tags:
• author:yqthz

一直想学习Rust, 趁着这次训练营的机会, 开始了我的Rust学习, 初学Rust时, 就感觉Rust的设计十分现代, Rust的所有权机制让内存管理变得十分高效且安全, 减少了很多的内存问题, Rust的所有权、借用和生命周期模型可以在编译期防止常见的内存错误（如悬空指针、双重释放等），无需依赖垃圾回收器。

最初，我发现所有权模型与传统编程语言（如C++或Python）非常不同。理解所有权和借用规则如何影响变量的生命周期和作用域是一大挑战, 通过Rustlings的练习, 我逐渐掌握了Rust的语法和特性, 也感受到了Rust的魅力, 在编写Rust代码时，需要细致地思考数据的生命周期、所有权和借用，这培养了我编写安全代码的习惯。

Rust的学习让我认识到了一种与传统语言不同的编程思维模式，也让我理解了系统编程中的许多细节。虽然Rust的学习曲线相对较高，但它所带来的性能和安全性是非常值得的。我期待在未来的项目中更多地使用Rust, 充分返回Rust在内存安全和性能上的优势

title: 2024秋冬开源操作系统第二阶段总结-yqthz
date: 2024-11-08 13:24:05
categories:

• report
  tags:
• author:yqthz

rcore的实验还是有一定难度的, 需要仔细阅读框架代码, 了解rcore的整体设计
lab1是实现sys_task_info系统调用, 比较简单
lab2是实现在启用虚拟地址的情况下重写sys_get_time和sys_task_info, 并实现sys_mmap和sys_munmpa系统调用, 难度较大, sys_get_time和sys_task_info仔细阅读sys_write的实现就可以完成, sys_mmap和sys_munmap做了一定简化, 在实现过程中需要对框架代码中的地址空间, 页表有较深的理解
lab3是实现sys_spawn和stride调度算法, 比较简单
lab4是实现硬链接和获取文件信息的系统调用, 难度较大, 也是我花费时间最多的一个lab, 需要仔细阅读框架代码中文件系统的实现, 需要对inode和disk_inode有较深的理解, 最开始尝试实现的时候, 卡在了如何读取disk_inode上, 后面又重新读了一遍框架代码, 一点点把文件系统的各个层次弄清楚, 最后成功完成了这个lab
lab5是实现死锁检测, 这个lab不需要阅读太多的框架代码, 只需要理解死锁检测算法即可, 难度一般, 最开始的实现的时候, need矩阵花费了我较多时间去理解, 在反复阅读测试用例和算法后, 我开始理解了这个算法, 最后成功实现了这个算法
最后, 非常感谢训练营将这么优质的内容开源, 同时提供了这么一个平台把大家聚集在了一起, 在与大家的交流和学习中, 我收获很多, 在阅读文档和框架代码的时候, 对os的许多概念有了实际上的理解

项目github 地址 https://github.com/xuejianxinokok/igb-driver/tree/xue_2024_a

文档地址: rust/IGB网卡.md · xuejianxinokok/mysqldoc - Gitee.com

第三阶段总结报告

学习

跟着看了大课，第一周的实验题尝试解决了，到第二周的宏内核后时间紧促就先看课了。

这里我谈谈我对于课程内容的理解吧。

首先是Unikernal,直观的第一眼看的话，Unikernal像是不划分用户空间和内核空间的操作系统，
同时也没有页表机制，不开虚拟空间，内核是一次写好的，app加载是配置文件一个一个分配的。这样的内核
就像是实验室产品一样，用户都是开发者权限，它的性能也是极度的优异。不过嘛，不分权，所以安全性很容易受威胁

接下来是宏内核，宏内核是常见的平时家里用的操作系统模式，宏内核地址空间的引入好处益处在学习操作系统时是所有人必背的。
它的内存分配，进程调度，也都是耳熟能详的。

最后是这个hypervisor，我最开始学习的语言是C，后面走了C++，所以对于虚拟机的机制只是略有耳闻，这里更深入的
探讨了虚拟机是如何实现，虚拟机的实现使

思考

异构扩展化的操作系统内核是个很令人兴奋的话题，就是这个内核你不能当他是某一个具体的内核，它可以执行各种app，关于异构
在智能物联这我有个想法，就是如果说是各个物品之间的交互的话，可以用统一的协议。那如果，这些物品可以在物理上链接在一起，
那么可不可以执行一个新的效果？就是比如，全屋有一个统一集中的管家，它是有个物理实体的”大脑“的，很多家电与它是进行”硬链接“，进行更快速，更高效的交互，控制。
当然，也可以通过网络链接，不过这是提供了另外一种方式。

方向

我选择本期的方向四，基于协程异步机制的操作系统

第一阶段

参加训练营让我了解到有 rust 这门语言，以前写c/c++习惯了指针的自由操作，刚开始非常不适应，但随着之后的学习越来越爱。
Rust 兼顾安全与性能，Rust的所有权机制让内存管理变得十分高效且安全, 减少了很多的内存问题, Rust的所有权、借用和生命周期模型可以在编译期防止常见的内存错误（如悬空指针、双重释放等），无需依赖垃圾回收器。Rust 编程思维不同于传统的面向对象，我认为更像是面向数据。

第二阶段

训练营给了我交流与实践的平台，通过参加此次训练营我学到了很多关于操作系统的知识，也让我了解到了在操作系统领域最新的研究与技术。
从裸机运行到单道批处理系统，学习了如何通过操作系统将程序与硬件隔离，提高安全性和资源利用率。rCore通过硬件的运行特权级划分和系统调用来实现多程序批处理，将程序编译链接成bin文件，加载到内存中的约定地址执行。进一步地探索了进程调度的机制，理解了时间片和CPU利用率的关系，以及如何通过TCB（任务控制块）来维护程序的关键信息，实现程序的切换和调度。
在内存管理方面，学习了从物理地址到虚拟地址的转变，以及MMU（内存管理单元）的重要性。rCore采用SV39内存管理策略，通过页机制和多级页表提高了内存的灵活性和安全性。对外存的管理，我了解了文件系统如何抽象和管理系统资源，以及rCore如何通过文件描述符（fd）框架来统一管理文件和设备。
线程与进程的学习让我认识到了操作系统调度的复杂性。RCore通过线程的引入提高了响应速度和调度效率，同时使用信号量和互斥机制来解决线程间的冲突问题。
总的来说，RCore的学习不仅加深了我对操作系统的理解，也锻炼了我的系统编程能力。通过实践，我对操作系统的许多概念有了更实际的认识。

Rustlings 练习总结

作为一名前端全栈开发者，刚开始学习Rust时，给我的感觉是没想象中的难度那么高，学起来还挺轻松…
然而，还是太年轻了，当我开始真的用起来之后，我发现，编译器成为了我前进的“恶梦”，它无时无刻不在教我做人，总是会在不经意间鞭挞我：“你，还很菜呢！”
所以，慢慢的，我开始放弃了保守的学习方式：“先将文档中的内容都大致学会，并记下来”，它让我一直停留在学习的舒适区，对学习Rust来说是很低效的。
Rustlings 其实就是一种很好的学习语言的方式，通过大量的几乎全覆盖式的Rust练习，在练习中不断遇到问题，并解决问题，就像打怪升级，心理上会不断的得到激励感，并不断的做下去。
通过Rustlings的110道题目的练习，其实也让我意识到了，自己以为的会使用Rust了，只是井底之蛙吧了。
练习的内容虽然都在文档中，只看文档学习的化，其实有时候会忽略这些知识的真实用途是什么，也就无法在实际项目中灵活的去使用了。
通过这段时间的练习，不一定让我在Rust的熟练成都有很大的提升，但是让我看到了一个Rust用法的大纲，这已经是一个很好的开始了。
希望在接下来的开发里，不断精进对Rust使用，当然，也不能只专注在语法本身，对操作系统本身知识的学习，会更重要，非常期待！

第一阶段学习总结-ZhongkaiXu

写在前面

这是第二次写rustlings，两个月前应实习要求第一次学习rust和rcore，这次和上次相比稍微熟练了一些，从最开始的一头雾水，到现在已经对rust的简洁性佩服得五体投地。接下来要一些smmu相关的开发，借着这个机会再熟悉了一下rust。以下是一些学习心得。

学习心得

我认为的rust的核心思想

我觉得rust里最重要的是所有权机制，一个value只能对应一个所有者，即使是函数传参也是一样，虽然刚开始有些不习惯，但是慢慢发现对于锻炼系统软件开发者的思维很有效。

文档

在做题的时候我会同时打开rust文档，因为太多东西记不住了，需要随用随查，抛开水平不够，感觉这还算是一个不错的习惯，开了一个好头，毕竟后面几个阶段的学习必须依赖riscv/arm的手册。

最有挑战性的

我觉得在使用rust开发过程中，最难的地方在于如何把程序写的“rust”，比如对于寄存器的访问，rust中有一些优秀的宏如 registers_struct! ，第一次看到这个东西之前还一直停留在c风格的编程思想，包括写的一些算法题也是没有完全发挥出rust的语言特性，希望在后面学习的过程中多参考一些优秀代码，养成好的习惯。

未来展望

马上进入二阶段的学习，临近6月也要做很多其他的工作，希望能做到WLB吧，把握和优秀的同学们交流的机会，学到更多东西。

第二阶段学习总结-ZhongkaiXu

写在前面

终于在最后一天完成了五道题。

这是第二次写rCore的课后练习题了，之前偷的懒也还回来了。前三个练习之前写过，就还算顺利，后两个卡了蛮长的时间。

学习心得

模仿

其实练习里面需要自己构思代码的部分不多，大部分都是在原有代码的基础上添加一些辅助的功能，只要能设计好思路，剩下的就是模仿已经实现的代码。

比如mmap的实现，我最开始想用现成的 insert_framed_area，然后还写了一大堆判断是否重复映射的函数，结果在munmap的时候又要整个考虑释放area的部分页，写的自己都懵了。后来回头看原有代码的实现，发现其实mmap就是一个 insert_framed_area 的删减版，不需要area那么大的粒度，直接模仿area里面的btreemap设计一个容器，再重用 insert_framed_area 的代码就行了..

再比如发现自己还是没法摆脱c的风格，for能套个好几层，不过好在能想到rust里面应该不用这么麻烦，然后回头翻原有代码，看看其他地方怎么用迭代器的。

大胆写 反正有rust_analyzer 反正可以rollback

现在写rust没有那么提心吊胆怕和编译器同归于尽了，还是自动补全的功劳，很多地方分不清要不要解引用、分不清数据类型，不过rust_analyzer会搞定的。

有些时候乱写一通，最后发现内核挂掉了，只好rollback了，也在群里问过把仓库污染了怎么从头开始，不过大胆写也好过不写，经过n次rollback总算能上手敲代码了。

未来展望

第三阶段hypervisor我来了！

title: 2024春夏季开源操作系统训练营第一阶段总结报告-fengtdi
date: 2024-04-24 21:38:58
tags:
- author:zlh20040308

2024春夏季开源操作系统训练营第一阶段总结报告

前言

了解到这个训练营源自一次机缘巧合，刚学完操作系统的鄙人在b站刷课时无意刷到了前训练营的导学部分，并在评论区看到了up主留下的链接，点进去一看正好都是我很感兴趣的方向，而且学习资源和github页面都整理得很完善，于是果断加入了

Rust编程基础

初探

第一阶段的的主要任务是学习Rust语言，刚接触这门语言时候的第一感觉就是概念十分的多，有些概念甚至看起来匪夷所思，如生命周期标注，我十分不理解为什么Rust要这么设计，但是秉持着能跑就行的原则，还是硬着头皮和编译器作斗争

初窥门径

带着以上这些问题，我找到了斯坦福大学CS110L这门课，这门课并不是教学生如何进行Rust编程，而是希望通过Rust的视角反映出当今两种主流内存分配机制——手动管理（malloc&free）和垃圾回收（GC）——的不足，在其三节课就主要讨论了它们所会遇到的问题：

• 手动管理（C/C++）

  C/C++的类型系统对内存所有权的表达能力是十分有限的，以至于工程师在设计函数接口时会显得十分臃肿，还必须附上大量的注释来告知调用者去担负起管理内存的责任，也就是说内存的管理取决于程序员的自觉性，这就导致程序员经常会忘记之前申请过释放内存，而且随着工程的不断壮大，这种错误会不可避免地发生

• 垃圾回收（Java）

  Java通过某种类似于引用计数的方式来自动回收内存，但这种设计会带来性能上的损耗（回收机制过于复杂）

而Rust便带来了属于它的第三种方案，那就是所有权机制，在这种机制下，内存管理会变得高效且安全，这得益于它强大的静态检测机制，能够在编译时期就规避掉很多内存泄露的隐患

但这也是有代价的，既然要求在编译时期就能发现错误，那么Rust编译器就会要求程序员在编码时附带足够多的信息供它推断，也就出现了类似于生命周期标注这些语法

牛刀小试

在初步过完几轮Rust基础并完成了rustlings之后，便开始着手用Rust复刻了一些之前写过的小项目（当然，还有那令Rust新手望而生畏的链表），在这段过程中越发能感受到Rust的一些设计理念在影响着我的编码习惯，也引起了我对与内存安全的思考

总结

在经历了这一阶段的学习后，虽然我到现在也不认为我是一个Rust程序员，但是也多多少少能用Rust去进行一些有效编码了

十分感谢第一阶段中为我答疑解惑的老师和同学，同时更要感谢开源操作系统训练营提供了这么一个平台把大家聚集在了一起，我十分喜欢这里的学习氛围，大家一起交流着学习上的疑惑并提出自己的见解，这开源的理念也使我收益颇丰

第四阶段总结报告

一些碎语

我查看了三篇文档 ， 其中https://os.phil-opp.com/async-await/#pinning

新使用的crate：crossbeam ,conquer_once

为啥使用conquer_once的OnceCell而不是lazy_static!因为这个类型实现
了避免中断程序进行堆空间开辟（从而避免产生一个死锁）

future 中还有一个Stream的trait
tokio文档看了一下（trait回忆一下，它像个接口，implement后应用到具体的一个类型）

Tokio 文档阅读

chat

首先阅读的是一堆example，这里先看chat。
chat是一个聊天室，设立服务端然后异步读取其他客户端的消息，并且广播到是所有的客户端，
是一种中心式结构

io_uring

与linux

linux有一个自己的原生异步IO接口，叫aio,他有一些问题：

1. 因为0_DIRECT，所以很多的IO用例不适用。普通的IO会退化为同步IO。
2. 就算异步，IO也可能会阻塞，比如硬件部分，这使得软件必须获取加载这些部分的锡信息
3. API不够完美，每次提交需要64+8字节的内存，每次完成徐娅萍
   他常用的方法是：io_submit() , io_setup() , io_getevents().

io-uring 和 epoll。

epoll 只是通知机制，本质上事情还是通过用户代码直接 syscall 来做的，如 read。这样在高频
syscall 的场景下，频繁的用户态内核态切换会消耗较多资源。io-uring 可以做异步 syscall，
即便是不开 SQ_POLL 也可以大大减少 syscall 次数。

io-uring 的问题在于下面几点：

兼容问题。平台兼容就不说了，linux only（epoll 在其他平台上有类似的存在，可以基于已
经十分完善的 mio 做无缝兼容）。linux 上也会对 kernel 版本有一定要求，且不同版本的实现性
能还有一定差距。大型公司一般还会有自己修改的内核版本，所以想持续跟进 backport 也是一件头疼
事。同时对于 Mac/Windows 用户，在开发体验上也会带来一定困难。

Buffer 生命周期问题。io-uring 是全异步的，Op push 到 SQ 后就不能移动 buffer，一定
要保证其有效，直到 syscall 完成或 Cancel Op 执行完毕。无论是在 C/C++ 还是 Rust 中，都
会面临 buffer 生命周期管理问题。epoll 没有这个问题，因为 syscall 就是用户做的，陷入 sy
scall 期间本来就无法操作 buffer，所以可以保证其持续有效直到 syscall 返回。

smol

在几个库的基础上封装成最后几个接口

在 Linux 上，mio 使用 epoll 来实现高效的 I/O 多路复用。smol 使用 mio 来实现
这一点。具体来说，smol 会将 I/O 操作抽象为异步任务，然后将这些任务交给 mio 处理。
mio 通过 epoll 监听文件描述符，当某个文件描述符变得可读或可写时，它会通知 smol 来
执行相应的任务。

在 smol 的源码中，底层通过调用 mio 提供的异步 I/O API 来实现任务的异步调度。例如
，读取数据时，它会发出 epoll 查询，直到某个文件描述符准备好读取数据，才会从事件队列中获
取该事件并执行对应的异步任务。

关于我的运行时

用proactor包装io_uring实现基本的异步读写，然后再包装proactor实现io和file，然后没有什么了，
一开始低估了整个运行时的大小

然后看了很多的文档：

https://github.com/rust-lang/futures-rs/blob/master/futures-core/src/stream.rs
https://rustmagazine.github.io/rust_magazine_2021/chapter_12/monoio.html
https://github.com/bytedance/monoio/blob/master/docs/zh/io-cancel.md
https://github.com/ihciah/mini-rust-runtime/blob/master/src/tcp.rs
https://github.com/rust-lang/futures-rs/blob/master/futures-core/src/lib.rs

这里我认为monoio算是一个正确的，完善的运行时，不过这个大小太夸张了，可以下期一开始就把它粘出来，让大家
直观感受一下成果的规模。