由于 11 月事情较为繁忙(比赛和研一课程等),因此三阶段实际花的时间并不是很多,加之 ArceOS 项目的复杂性较高,导致这一阶段个人的学习效果不算太理想,对项目的代码框架还不算很熟悉。后续准备深入啃一啃各模块的源代码,并在四阶段深入学习 Hypervisor 虚拟化方向。以下是我在三阶段过程中的学习日志。
2024秋冬季开源操作系统训练营三阶段学习总结报告-邵志航
ArceOS入门
依本人的拙见,三阶段其实是为了让大家在正式开始项目实习前,先弄明白我们接下来要开发或者要完善的这个OS到底是一个什么样的OS。换句话说,它到底是基于一个什么样的思想去构建的?它跟市面上已有的那些微内核或者宏内核有哪些区别?或者更近一点,它跟我们之前做的rcore又有哪些异同?这应该都是我们在ArceOS入门阶段需要了解的一些事情,弄明白了这些概念是为了给接下来的开发和项目实习打下一个良好的基础。
组件化内核的概念
研究和实践基于组件构造内核的方法,尝试构造应对不同场景的各种模式内核。
前两天才考完操作系统,在书本上,对操作系统的(其中一种)定义是这样的:
操作系统是一组能有效地组织和管理计算机硬件和软件资源,合理地对各类作业进行调度,以及方便用户使用的程序的集合。
感觉有一种异曲同工之妙。即,我们也许不用将操作系统看作一个完整的整体,而是一块块组件,我们通过“胶水”进行粘合,将这些组件组合成一个程序的集合,来实现诸如计算机软硬件资源管理等功能。
在组件化内核领域:所有内核实例都可以基于组合组件的方式,从简单到复杂逐级迭代的进行构建。所有内核模式都可以看作以Unikernel模式为基础,朝向特定方向的组件化扩展。
那么什么是unikernel?
Unikernel
Unikernel模式下应用与内核处于同一特权级(均为内核态),共享地址空间。Unikernel既是内核又是应用,二者合为一体。
转换到实际场景中,我们可以理解成就是一个运行在开发板上的程序,只是这个程序直接操控了这个开发板的所有硬件资源,且它只做一个任务,比如U1.0,负责向屏幕上输出信息,随后终止,退出。
而从上面的例子中,我们又可以将一个简单的输出字符串的程序,分成几个部分。比如输出部分,架构相关的部分,给分隔开,并且各自作为组件再完善,成为了组件化内核的前身。
优势:二者之间无隔离无切换,简单高效。
劣势:二者之间无隔离无切换,安全性低。
小结:通过U_1_0:helloworld,建立最基本的框架:核心组件axhal、axruntime、api、ulib以及上层应用组件。
后续版本在该基本框架的基础上,通过扩展功能组件,扩展OS能力特性。
这里扩展的部分,就是axalloc, axtask, axsync等
从Unikernel到宏内核
相对于Unikernel,宏内核的特点:
(1) 增加一个权限较低的用户特权级来运行应用。
(2) 为应用创建独立的用户地址空间,与内核隔离。
(3) 内核运行时可以随时加载应用Image投入运行。
(4) 应用与内核界限分明。
为了将我们的工作进一步推进到宏内核,我们还需要实现几个组件,其中就是axmm,用来构造用户地址空间和axfs,加载应用程序代码到地址空间。
Hypervisor
这部分暂时没有做更多的了解,因为本人想参与宏内核的开发,更多的去学习宏内核的相关知识了。此外,软件所的任务也一直在做,于是还没来得及看。
课后练习
主要是在于bump_allocator以及对挑战题目第1题的理解。因为之前也一直在做内存分配这里的工作。
bump_allocator主要还是根据bump分配器本身的一些思想去填充对应的功能即可。
而挑战题目通过优化内存块的分配来提升内存空间的使用效率,使得Indicator这个指标有显性的提升。我的实现是基于slab的,准确来说,只是修改了某个内存块的大小限制,所以优化也没有那么明显。
祝接下来项目阶段好运!
姜鹏组件化内核实验报告
week 1
print_with_color
思路:直接修改 axstd 里面的 println!宏,在输出的内容之前加上ansi的控制字符串
1 | commit 29c8b52df3644c27ea1f2cb26191e7a45c2c40a4 (HEAD -> exercise) |
support hashmap
思路:axstd 中新增collections模块,将 alloc::collections 中的容器导入。此外,注意到std::collection::hashmap是在hashbrown作为base进行使用。尝试与std做一样的事情,发现可以直接将hashbrown模块引入作为hashmap使用,randomState就采用了默认的。
1 | commit c2cab71c6640a9c9f984144f2e12f701cf347f31 |
bump 内存分配算法
分配bytes
实现较为简单,用b_pos记录当前内存bytes分配到的地方。 唯一需要注意的是
- 要根据aligment返回起始地址。并将分配计数+1
- 要检查 b_pos + size是否到达了 p_pos,是的话说明内存已经被耗尽。
分配pages
实现也较为简单,用p_pos记录当前pages分配的地方。需要注意的是- p_pos是递减的,返回的地址会越来越小
- 要检查p_pos - size是否到达了b_pos,是的话说明内存已经被耗尽。
释放bytes
- 引用计数减1,然后检查是否为0即可,为0的话就将b——pos重置。
mv和rename操作
mv
分解为 create + del 两个动作,在新的地址上写入原文件,然后删除原文件
rename
文件系统有相关api,直接调用即可。
1 | commit adabd01bad84c50a172a5a43af4d7cb77d75c4d7 |
week2
pagefault 缺页处理
populate参数为false时,uspace模块只会为将该块虚拟内存地址记录下来,实际的访问会导致 pagefault, 在该handler中处理这一错误
1 | commit c0ed66e6fd0ad5af24f7ae6b2e683c43df03228a |
mmap syscall
与page fault处理类似,有相应api可以调用
1 | commit daef0f232f4ae709afe1ef19974afa29b4594c95 |
week 3
simple hv
这个题是面对用例编程,分析下面的程序
1 | unsafe extern "C" fn _start() -> ! { |
结合下面的代码,知道是需要我们将GUEST的a0设置为0x6688, a1设置为0x1234。
1 |
|
最终实现如下:
1 | commit 325d23818ae08961b4cf8e8d500b90f04dbd98d3 |
hv_pflash
思路: 用upload img脚本将pflash传到 disk.img 中,然后在处理异常地址时读取该文件,将该文件的内容映射到 pflash 所在的地址即可。
1 | commit d3959ba050e8d4fcbd764415b0bac71be5a2013b |
2024秋冬季开源操作系统训练营第三阶段总结-hbuxiaofei
[print_with_color]
: 支持带颜色的打印输出。
- 要求:
- 修改一个组件的实现
- 执行
make run A=exercises/print_with_color
预期:字符串输出带颜色。(具体颜色不做要求)
提示:在不同层次的组件上修改,影响的输出范围不同。例如,修改
axstd
可能只影响println!
的输出;修改axhal
则可能一并影响ArceOS启动信息的颜色。
- 本次修改主要集中在
println!
宏中,修改后的代码如下:1
2
3
4
5
6
7
8macro_rules! println {
() => { $crate::print!("\n") };
($($arg:tt)*) => {
- $crate::io::__print_impl(format_args!("{}\n", format_args!($($arg)*)));
+ // $crate::io::__print_impl(format_args!("{}\n", format_args!($($arg)*)));
+ $crate::io::__print_impl(format_args!("\u{1B}[{}m{}\u{1B}[m\n", 32, format_args!($($arg)*)));
}
}
[support_hashmap]
: 支持HashMap类型。
- 预备:执行
make run A=exercises/support_hashmap
要求:
- 在axstd等组件中,支持
collections::HashMap
- 再次执行
make run A=exercises/support_hashmap
- 在axstd等组件中,支持
提示:
- 报错的std其实是axstd,测试用例main.rs中有”extern crate axstd as std;”
- 在axhal中给出了一个随机数产生函数random(),可以基于它为HashMap提高随机数支持。
- 实现思路
HashMap 使用一个 Vec<Option<(K, V)>>
来存储键值对,每个桶(即 Option<(K, V)>
)存储一个键值对,空桶为 Nonecustom_hash
函数用于生成键的哈希值,这里采用简单的字节移位和异或方式,返回一个 u64 类型的哈希值iter
方法返回一个自定义的迭代器 HashMapIterator
,该迭代器遍历哈希表中的所有已存储的键值对
通过线性探测法处理哈希冲突,即当发生冲突时,依次检查下一个桶直到找到空桶或找到匹配的键。
- 测试结果
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19d8888 .d88888b. .d8888b.
d88888 d88P" "Y88b d88P Y88b
d88P888 888 888 Y88b.
d88P 888 888d888 .d8888b .d88b. 888 888 "Y888b.
d88P 888 888P" d88P" d8P Y8b 888 888 "Y88b.
d88P 888 888 888 88888888 888 888 "888
d8888888888 888 Y88b. Y8b. Y88b. .d88P Y88b d88P
d88P 888 888 "Y8888P "Y8888 "Y88888P" "Y8888P"
arch = riscv64
platform = riscv64-qemu-virt
target = riscv64gc-unknown-none-elf
smp = 1
build_mode = release
log_level = warn
Running memory tests...
test_hashmap() OK!
Memory tests run OK!
其他实验由于忙于项目,暂时未做,后面有时间再补上其他的实验。
之前总结的一个starry的实现流程也记录这里,方便以后实验查阅:
Starry启动流程
2024秋冬季开源操作系统训练营第三阶段总结报告-sts
进入第三阶段当然很高兴,但时间上实在太紧,我一开始的心态是按看懂源代码中的每一步来走的,但目前只是看完了所有相关的 makefile,以及看了部分 PPT 中强调部分的源代码。实验的话也是完成了第一周的内容以及 Hypervisor 的实验一。
arceos流程小结
总体执行流程:axhal的boot.rs中先引导,用于初始化内核栈,设置初始的页表,这里映射了两个 1G 的大页,分别是低地址恒等映射以及高地址的一个映射。随后要调用 axruntime 的 rust_main 来进一步完善运行时,这里会涉及到 axfeat 里面用到的 feature 条件编译并初始化一些东西,比如启用了 paging 这个 feature 就会重新映射页表这样。调用 rust_main 的时候加了一个偏移,偏移的大小其实就是高地址映射的偏移这样。随后 axruntime 做好运行时之后,调用 main 函数。随后调用结束函数,结束整个流程。
课后练习1:支持带颜色的打印输出。
具体实现:修改axhal中putchar的实现,在打印每一个字符时都加入相应的转义字符。
关于转义字符的具体解析的话:颜色定义的部分可以参考 console_codes(4) — Linux manual page 的 ECMA-48 Select Graphic Rendition
部分。在 makefile 中的 run_cmd
函数用于辅助输出同时会以颜色输出命令,参数 1 控制颜色为白色,参数 2 控制为灰色,随后执行命令。
颜色控制部分关键如下
1 | param result |
ECMA-48 SGR
序列以 ESC[ parameters m
的格式控制显示的属性。parameters 用分号隔开,\033[92;1m
为例,033 为八进制,表示 ESC,92 和 1分别是 param,参考上文的 ECMA-48 Select Graphic Rendition
92 表示绿色明亮前景色。1 表示加粗,0 表示重置属性。
课后练习2:支持 HashMap
ax_api 作为下层 module 的抽象,随后 axstd 作为我们自己定义的标准库供用户程序调用。
我的想法其实也是直接看 std 的 HashMap 怎么实现,然后改一改,做到最小的满足测试案例中的那些操作。然后慢慢改一改,后面看到官方也用了 hashbrown 作为实现,然后我就改了改,把随机数用到 hashbrown 这边大概。然后就好了。
课后练习3:实现 alt_alloc
这个分配器应当是用作早期boot之后系统初始化阶段的内存分配器,所以实现上相对简单,每次分配都向后增长。dealloc的时候尝试减掉已经alloc的空间大小,如果为0,那就重新开始从头分配这样。
挑战题目:实现特定分配算法
这个算法的话,还是要感谢万能的群友,我一开始想的也是在TLSF基础上改一改这样。后面发现有取巧的地方,主要也是循环一直进行,奇数项的内容永不释放,所以就取巧了,会记录每次奇数次申请的空间,下次申请如果比上次的小,那就返回该地址。如果比上次大,那就重新申请,释放上次的内容这样。
达到的轮次是65536应该是,也是一个非常 unsigned int 的值。
思路详细描述:由于每次申请的空间大小会加1,相比上一次。例如,delta 为1,申请的空间依次是32 + 1, 32 * 2 + 1, 。delta 为 2,申请的空间依次是32 +2, 32*2 +2,。所以,第一次循环会反复替换掉分配器中的记录。
但是,从第二次开始,每次当 index 为 13 的时候,会替换上一次的内容。因为上一次的 13 比这次的 13 申请的空间小 1。但是呢,14 不是最后一次循环吗,因为 14 是偶数所以不管。奇数就很神奇,每次都是到 index 为 13 的时候重新申请一次空间。其余时候,其实大家返回的地址都是一样的。嘿嘿。而且,每次替换的时候都会把上次的给释放了,哎,就很神奇。
首先主体部分使用特定内存分配器 tlsf。包括申请,释放等操作。
其次,定制 alloc 函数。用 indicator 记录此时调用 alloc_pass 函数的 delta值。用 index 记录 alloc_pass 函数中的循环次数。
alloc 的时候需要谨慎计算,2的多少次方啊,当index = 14 的时候,重置为 0,然后indiactor需要加 1 啊,之类的。
这里要注意一点,源码里,分配器有个special变量,为bool类型。这里用它的主要原因在于有个很神奇的点:当indiactor为32, index = 1的时候,items需要申请 0x60 的空间,而恰好,下次申请向量空间也是 0x60 的大小。就,重复了。嗯。所以,作为单独判断条件,然后重置,第一次出现先不管,然后继续。然后,bug解决。
Hypervisor课后练习1
hypervisior流程分析:这里初始化阶段我们的hyper会布置好一个现场类似我们在宏内核中设置好sstatus寄存器那样,随后通过sret到GUEST中执行,GUEST中遇到无法处理的情况又会陷入Hypervisior中,通过对不同类型的陷入执行不同的代码,处理好用户的错误设置寄存器等操作,随后返回GUEST继续执行。
这里的第一个实验比较简单:只需要在处理错误函数中设置寄存器的值,然后设置sepc += 4,让GUEST去执行出错指令的下一条指令即可。
Hypervisior课后练习2
这里会涉及到虚拟化里的地址二阶段映射。主要流程:GUEST中的虚拟地址先通过 VSATP 翻译,通过 GVA 到 GPA,然后通过 HGATP 把GPA翻译到 HPA 这样。
课后练习尚未完成,嗯。
Hypervisior课后练习3
这里涉及 GUEST 的中断。主要涉及时钟中断,一种实现方式是当 GUEST 配置 RTC 的时候会陷入 Hyper,由 Hyper 来设置时钟,当时钟触发的时候,Hyper 会触发 GUEST 的时钟中断位这样。Hyper在设置完之后应该是会关中断的,待下次GUEST设置中断的时候再打开,这样保持一致。
课后练习尚未完成,嗯。
总结
这里总结的话,三阶段实在不完美,时间上太赶了,然后各种东西都想弄明白细节,这样就很来不及。原本还准备看RISCV的指令集虚拟化扩展这样,也只看了一小部分,内容上其实不算多,但要补的内容比较多,就比较费劲。
2024秋冬开源操作系统训练营第三阶段总结-chy669086
也是很高兴能进入三阶段学习。三阶段让我对操作系统的理解更进一步,通过课后的作业,我也学到了不少知识。
个人收获
- 学会了操作系统对设备的挂载
- 了解了 unikernel 到宏内核的转化
- 对操作系统内存分配的了解更进一步
- 通过查漏补缺对上一阶段掌握不熟的知识进行了复习
通过阅读 arceos 的源代码和课后练习,我的程序编写能力也得到了锻炼,让我对操作系统有了全新的认识。
未来展望
通过这个阶段的学习,我有以下打算:
- 四阶段希望进行宏内核的学习
- 在寒假时间自己实现一个轻量级的 unikernel 内核,并通过组件化的形式将他变成宏内核
最后,感谢老师的悉心教导,也感谢平台提供的学习机会,让我有了深入学习操作系统的机会。
stage-2-ProerLoneW
rCore第二阶段总结报告
第二阶段回顾
本以为第一阶段后将是一马平川,却不曾想第二阶段竟是噩梦的开始。本以为第二阶段也和第一阶段一样,只需断断续续抽出一周的零碎时间即可轻易完成,但只有亲身尝试过才会知道这种想法多么的错误,最后几乎是推掉了所有的学业任务,把一整周都投入在了rCore上才勉勉强强卡ddl写完了所有lab。
第零章和到第二章可以说是第二阶段的环境配置和任务理解阶段,由于上一阶段仅仅是在mac电脑上轻松写代码,故在一开始的环境配置上还是耗费了小两天,在此过程中第一次接触到了windows的wsl,然后一步一步在实验指导书的指导下搭建了 vscode + wsl + ubuntu20.02
这样的开发环境,在阅读前面几章的文档内容后也对所学的知识、实验的相关方向有了大致的了解,并能够初步运行起来自己的rust-os。在第一章的学习过程中,我理解了应用程序的执行环境,对 应用程序、函数调用、标准库、系统调用、操作系统、指令集和硬件平台
这些概念又有了新的认识,有种学习汇编语言的感觉,另外也接触到了 裸机编程、目标三元组
这些比较新的东西。但也仅停留在有印象的层面,没能深入理解其中奥秘;第二章的内容比较全面,我了解到了应用程序执行过程和操作系统的特权级切换机制,了解了编写risc-v的链接脚本来控制内存布局、内嵌汇编、异常处理、上下文切换的实现,这些操作在代码中的实现,更是让我操作系统的课上所学映入了现实,第二章的批处理调度系统,也是一个很好的帮助我入门并理解整体的代码架构的案例。
后面几章就没有那么多时间细细咀嚼了,通常都是扫两眼知识然后直奔作业,除了文件系统外,其他由于都在课上学过,因此在gpt的帮助下没有被卡住太久的时间。也很感谢用心设计该实验教程的学长/学姐,不仅让我们快速入门了os,还让我们快速了解了如何系统开发一个os的各个功能。
在lab1实验就卡了很久——不会仔细品读知识中所蕴含的代码实现细节,也不会投机取巧地去看看测试用例和作业所给的提示,而仅仅是闭门造车,最终卡了许久才在群聊天记录中找到了问题的关键所在,也就是时间的记录问题,当然在写的过程中也遇到诸如生命周期等等问题,让语言基础不太牢固的我举步维艰。
lab2是虚拟存储多级页表实验,虽然在课上老听说页表的神奇和重要性,但从没有像本次实验这样深刻地接触过操作系统中的页表,最初做的时候由于考虑的太多又无法实现便导致一度停滞不前,后来在发呆的时候又仔细重新阅读了一下题目的要求,发现需要实现的东西都还挺简单的,而且测试用例也给的非常宽松因此很快的做完了,并没有想象中那么复杂。
lab3是有关进程的简单创建和调度,实现上并不困难,主要难度还是在于代码结构发生了较大变化,比如本来 task_manager
做的事情现在换成了 process
在做。
lab4是最痛苦的一次实验,在把ch5的代码移植过来后发现仅需要过三个测试文件即可便觉得它很简单,但真正想要得心应手地写出来需要对文件系统和代码实现有详细的理解,最终还是在听了ddl前的讲解才恍然大悟:linkat和create略像前一章所提到的fork和spawn,否则将根本无从下手然后白白浪费时间并放弃之前的一切努力。在给 inode
加上 inode_id
相关的方法后很快完成了这次实验。
lab5的内容相对比较熟悉,也是课上自认为十分简单的死锁检测问题,但代码框架阅读起来难度较大,最终将前面的 sys_get_time
搬过来后跟着题目的提示实现了资源分配图和死锁检测系统调用的实现
第二阶段收获
这次的第二阶段学习就像一场不断挑战极限的马拉松,让我既感到疲惫不堪,又充满了意想不到的收获。在本阶段的学习中,我获得了关于操作系统核心机制的更深入理解,体验到了真实操作系统开发的复杂性和细致入微的编程要求,特别是在进程管理、内存管理、以及文件系统的设计上有了全新的认识。
首先,通过批处理调度系统的实现,我理解了特权级切换、上下文保存与恢复等机制。这种直接操控硬件资源的编程体验帮助我更好地理解了操作系统在管理硬件与应用间的角色。其次,在实现文件系统的过程中,我也是初次了解了文件路径解析、inode 管理和文件描述符等底层概念,这不仅让我理解了文件系统的设计精髓,也磨炼了抽象和模块化编程的能力。
同时,在死锁检测的实验中,资源分配图的设计让我更深刻地理解了进程间的依赖关系和并发控制策略,学习知识的最好方式绝对是动手实践。
总的来说,这一阶段的收获不止是技术上的进步,更让我体会到了系统开发的全局性思维和精确性要求。这不仅提升了我的编程能力,也让我更有信心面对后续操作系统开发中的复杂问题。
stage-1-ProerLoneW
rCore第一阶段总结报告
参加训练营的契机
本人是大三信息安全专业学生,起因是在学期初老师在班级群中转发了本次训练营的相关推送,正好本学期在修操作系统专业课,再加上在过去的两年实际上没有学过过硬的技术,就希望能通过本次训练营收获到许多实际项目开发相关的东西,希望能做到技多不压身。
第一阶段回顾
本阶段的主要任务是根据 rust语言官方圣经
来学习rust语法,并在简单的知识训练、算法实现中掌握基本的编程逻辑和rust语言的独特思维。在学习过程中最大的感受就是,这是一门非常“麻烦”(或者说拗口)、非常底层但却非常“安全”的语言。
在进一步地阅读文档和代码实操的过程中,我也深深地体会到了rust语言的魅力,很多在其他语言中不需要关注的问题,都是rust使用者的家常便饭,例如所有权与借用、生命周期、模式匹配、并发和线程、内存管理、特征泛型、智能指针、宏等等全新的概念,在学习的过程中,也能十分自然地和以往所写过的语言进行对比,也能十分自然地联想到自己所学的专业知识,整个学习过程是痛苦而充满趣味和成就感的。
最终也是断断续续地在国庆后完成了110分的编程题目,虽然很多地方都有囫囵吞枣、只求大概的不好处理,但还算是初步打开了rust语言的大门。
2024 秋冬季开源操作系统训练营 第2阶段(专业阶段 - OS设计实现)
阶段目标与晋级条件
从零开始构建操作系统的各个模块,不断完善操作系统核心功能
完成5道rCore操作系统大实验编程题,深入领会OS重要概念,掌握必备技能
排行榜积分达到500分,方可进入项目阶段学习,参与团队合作完成关键任务
阶段个人总结
从本阶段开始本人感到明显的学习吃力,各种新概念在教学过程中如泉涌般浮现在脑海,难以在短时间内完全消化完毕。 故专门抽出一整个周末以及课余时间反复研读与理解教学文档,深入洞悉各种新概念的内涵,在彻底理解相关知识点后再结合视频直播中老师的讲解理解每一行代码的实现逻辑(5W1H原则:Why(何因)、What(何事)、Where(何地)、When(何时)、Who(何物)、How(何法))。在确保完全弄懂文档知识点与代码的实现逻辑之后,方才着手完成每个实验的习题。
通过本阶段的学习,我也认识到学习操作系统相较于其他编程实践项目需要投入更多的精力,对于陌生的技术栈需要花更多的心思去理解其技术细节与应用方式,不能向以前一样盲目自信而心不在焉地学习。同时这几次实验也建立起我实战大型编程项目的经验,为以后参与更多更繁杂的编程项目打下基础。
2024 秋冬季开源操作系统训练营 第1阶段(基础阶段 - Rust编程)
阶段目标与晋级条件
Rust编程语言为学习操作系统设计与实现打下坚实基础
通过完成100道Rustling编程题,强化训练Rust编程技能
该阶段排行榜达到满分可晋级,进入专业阶段学习
阶段个人总结
Rust 语言是参加本训练营必须掌握的一门语言,因为本训练营的所有项目均基于本语言编写。由于本人已学习过 Rust 编程语言,故本阶段无太大压力,跟着晋级要求完成 rustlings习题后即达成目标。
而重点是后续专业阶段 rCore 操作系统的学习与代码理解,因操作系统相关知识早已忘记(虽然曾跟着网络教程阅读过 Linux 内核源码,但年代久远早已忘记细节),故需要一定时间重拾相关知识,并跟着实验在旧知识基础上提升自己的理解水平。
附:本人学习 Rust 语言的主要参考视频教程。