rcore-os Blog
0%

Posted on

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

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

荣誉准则

  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

实验总结

文件系统章节是我花时间最多的一个章节，时间主要花在了对文件系统的理解上，看源码也费了些时间。将细节通过在线文档整理如下图所示：
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

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: 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

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

Posted on

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的许多概念有了实际上的理解