rcore-os Blog
0%

Posted on

这次的学习rcore有点艰辛，因为是把一个操作系统内核给完成了，虽然也只是补充了syscall里面的函数，但是>把整体内核需要什么部件给摸索清楚了
出了有关rust语言特殊机制的bug，就看看别的函数是怎么写出规范的rust代码的，虽然看了文档后有个思路去写
那个函数，但是不知道怎么写时，参考周围代码就好多了，让我印象比较深的是，当一个结构体的对象要被调用>的时候，比如inner，通常需要加个exclusive_access（）或者unwrap（）等等，这个rust语言虽然没有像C语言>那么底层，但是感觉这么一写，就不会出现内存问题，很规范。再不会通常只能问大佬了哈哈哈。
在这个训练营，大佬云集，接触到了很多才学渊博的人，大家也来自不同的专业，有着不同的志向，也坚定了我>跨越专业去学习更多知识的信心。

Posted on

2024三阶段总结

Unikernel

  • print_with_color

简单的利用ascll字符实现颜色

  • support_hashmap

看群内大佬讨论，就引了一个库

  • alt_alloc

这个难度不大，因为测例很简单。严格实现后我确实也不知道自己实现的正确与否

  • shell

原shell实现了有关rename的，rename我就直接调库了，然后通过创建文件、copy文件内容、删除原文件拼接除了mv的功能

  • 1115挑战（内存调度算法实现优化）

说来惭愧，我这个印象最深。我写了3次，第一次好像是80多，第二次直接没跑起来，第三次是链表指针不知道指到哪里去了….反正都没超过170,也就没提交….

宏内核

  • page_fault

难度适中？ 感觉就是rcore上了一点

  • sys_map

就find_free_area然后read进去，虽然感觉用find_free_area找到的地方有些不符合man mmap的说明。

Hypervisor

第一次了解hypervisor具体是怎么操作、干了什么….涨知识了…

  • simple_hv

改一下guest的sepc，设置一下a0、a1的值

  • pflash设备模拟方式

一开始没有搞清gpa映射到hpa时，没有经过host的satp，导致在host中拿着pa当va来用，出现了问题。另外，在完成后，修改了一下pflash的内容，想要读u128转string输出，但是没想到，在对* u128解引用时，它居然会先读u128的高64位，导致映射时页面没对齐。

2024四阶段总结 - Starry-Next 项目二方向一 感想

仓库链接: https://github.com/yjymosheng/Starry-On-ArceOS/tree/main

最终 commit ID: 71650c57f8ef9a64a6bdf274d9890b5c0c96642d

目前进展:

已经完成的syscall

a

没有完成的syscall

b

个人感想 :

这时我第二次参加os训练营,第一次的时候连rcore都没有完成,这一次由于对syscall的理解不够,相比其他同学浪费了很多时间在img的调试上.

可能下一次就能拿到优秀学员证书了也说不定?一次更比一次强嘛

虽然我的四阶段的学习可能差强人意,但是对我来说算是打开了操作系统的大门,希望明年的操作系统大赛上,能够有新的突破.

通过这次训练营，我进行了第一次对操作系统的尝试,与还对系统调用有了更加全面的认识。编写一个自己的操作系统不再只是纸上谈兵，而是一种有希望实现的技术。回顾整个过程，既有苦涩，也有喜悦，更重要的是，这让我对操作系统这条路充满了信心和期待。

希望未来，我能够在操作系统道路上走得更远，探索更多未知的可能性！

Posted on

总结

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

笔记

第一题

应用分别出现：

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

第二题

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

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

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

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

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

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

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

荣誉准则

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

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

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

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

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

Posted on

总结

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

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

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

笔记

第一题

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

第二题

荣誉准则

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

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

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

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

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

Posted on

荣誉准则

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

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

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

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

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

Posted on

实验总结

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

问答作业

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

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

荣誉准则

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

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

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

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

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

Posted on

实验总结

问答作业

荣誉准则

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

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

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

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

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

Posted on

title: dream第二阶段总结
date: 2024-05-31 20:00:41
categories:
- 2024春夏季开源操作系统训练营
tags:
- author:Eternal60f3
- repo:https://github.com/Eternal60f3/2024-rcore-repo

很感谢这次训练营的主办方。我这学期准备考研，然后就也想这弄一个项目。为复试增加点东西。

rcore让我熟悉了gdb以及git的使用。借助vscode的插件也很方便的利用git来比对前后差异来debug。

对于这几个实验。

再看完ch3的文档，当时以为自己理解了，等实际去看代码的时候，发现自己理解个屁。又回到ch2分支，捋清楚ch2的代码之后，才搞懂ch3的实现。

实验4非常nice本来一开始一直没搞懂，为什么要设置 DiskInode 和 Inode 两层抽象，而不是一层，但实际开始写的时候突然意识到，这是对于fs资源保证只有一个人使用的管理。对于涉及到了锁的编程，以前没太写过，debug弄了好久。

实验5在群里和佬们交流了才搞懂该怎么弄，debug了也弄了好久。好在最后做出来了。

可惜，阶段三之后可能没啥时间弄了，得抓数学了。未来说不定还会来参加啦，哈哈哈。多谢清华给了这么好的学习机会

Posted on

Axsl666-2023秋季OS训练营第二阶段总结

首先感谢learningOS社区的所有贡献者。前几次训练营因为错过报名时间而未能参加，终于在2023秋季参与到了本次训练营活动。

实验一内容总结

多任务系统的简单实现

  • 扩展 TaskControlBlock：
    • start_time
    • started
    • syscall_times
  • 设计 TaskManager 的公共接口
    • add_syscall_times
    • get_current_task_info
  • 在相应函数中更新 TCB 数据, 记录开始时间：
    • run_first_task
    • run_next_task
  • 在系统调用处理函数中调用 add_syscall_times 更新 TCB 中的记录
  • 完成 sys_task_info 系统调用
    • 主要是调用 get_current_task_info 并返回 TaskInfo。

实验二内容总结

系统开启虚拟地址空间

重写 sys_get_time 和 sys_task_info

  • 在内存管理中增加 translated_mut_ptr 函数，实现进程用户地址空间中的指针到可变引用的转换
  • 其余类似 ch3 中的操作

mmap 和 munmap 匿名映射

  • 内存管理接口
    • delete_frame_area
  • 任务管理接口
    • mmap：调用insert_framed_area增加映射区域
    • munmap：调用delete_frame_area删除映射区域
  • 系统调用的实现
    • 合法性检验
    • 调用任务管理接口 mmap 和 munmap

实验三内容总结

实现进程管理相关系统调用

实现系统调用 spawn

  • 扩展 Task 公共接口
    • spawn
      • MemorySet::from_elf 新建地址空间，用户栈，程序入口点
      • 分配 pid 与内核栈
      • 建立 TCB
      • 加入父进程的子进程链表
      • 准备 TrapContext
      • 返回新子进程的TCB
  • 完成系统调用功能
    • sys_spawn

实现 stride 调度算法

  • 扩展 TCB
    • stride
    • priority
  • 扩展 Task 公共接口
    • set_priority
  • 修改 TaskManager 调度算法
    • fetch 修改为 stride 调度算法
  • 完成系统调用功能
    • sys_set_priority 调用 set_priority

实验四内容总结

实现几个文件系统相关系统调用

sys_linkat

  • 给 File trait 增加 fstat 接口
  • 扩展 efs 中 DiskInode 接口
    • get_inode_id： get_disk_inode_pos的逆过程
  • 在 vfs 中 Inode 增加接口
    • create_link
      • 新建目录项，(new_name, old_inode_id)
  • 完成系统调用 sys_linkat

sys_unlinkat

  • 给 File trait 增加 fstat 接口
  • 扩展 efs 中 DiskInode 接口
    • get_inode_id： get_disk_inode_pos的逆过程
  • 在 vfs 中 Inode 增加接口
    • delete_link
      • 遍历目录下所有目录项，找到与对应文件名相同的inode
      • 删除（清空）对应目录项
  • 完成系统调用 sys_unlinkat

sys_stat

  • 给 File trait 增加 fstat 接口
  • 扩展 efs 中 DiskInode 接口
    • get_inode_id： get_disk_inode_pos的逆过程
  • 在 vfs 中 Inode 增加接口
    • inode_id: 实现获取自身 inode id
    • isdir：判读是 inode 否为目录
    • linknum: 获取 root inode 下的某一个 inode id 对应的硬链接数量
  • 完成系统调用 sys_stat

实验五内容总结

本节主要几种同步原语与及其内核实现。

  • 加入死锁检测机制，实现银行家算法。
  • 扩展 PCB 和 TCB
    • 可利用资源向量 分配矩阵 需求矩阵
  • 数据更新
    • 相关系统调用时进行更新数据
  • 检测算法
    • 获取资源前进行死锁检测

Posted on

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在内存安全和性能上的优势