Kazomi
Kazomi
https://github.com/CelestialMelody/daily_schedule_for_os_traning_camp_2022
实验环境配置步骤推荐
[磁盘块管理器中 create 方法](http://rcore-os.cn/rCore-Tutorial-Book-v3/chapter6/2fs-implementation.html#id13:~:text=let%20data_total_blocks%20%3D,/%204097%3B) ``` rust let data_total_blocks = total_blocks - 1 - inode_total_blocks; let data_bitmap_blocks = (data_total_blocks + 4096) / 4097; ``` 有两个问题： 1. 为什么这里 `data_total_blocks`要减去1呢？ 2. 为什么这里是除 4097 而不是...
请教一下，heap_test 可以改为 rust 单元测试吗？（不太会改来用，感觉需要做一些其他工作，我会出现 `error[E0463]: can't find crate for test`的问题）
>这是因为，括号中的两项分别对应为了映射这段连续区间所需要新分配的最深层和次深层节点的数目，前者（对应第二级页表）每连续映射 2MiB 才会新分配一个 4Kib 的第一级页表，而后者（对应根页表，第三级页表）每连续映射 1GiB 才会新分配一个 4Kib 的第二级页表 请问，这里 `4Kib` 是不是打错了，是 `4KiB`（页表512个页表项，每个页表项大小8B）
关于《分析 SV39 多级页表的内存占用》，理论上的第一种上限： > 每映射一个 4KiB 的虚拟页面，需要初始就有一个页表根节点，因为还需其它两级页表节点，故最多还需要新分配两个物理页帧来保存新的节点。 没有太理解： 1. 为什么“最多还需要新分配 **两个** 物理页帧来保存新的节点”？ 2. 没有理解这里 'S / 4KiB' 的含义。这里的计算看起来就像是：每连续映射 4KB 新分配 2 个 4KB 的页表。
感觉一些概念的表述比较绕： > 在 SV39 中： > - 如果使用了一级页索引就停下来，则它可以涵盖虚拟页号的高 9 位为某一固定值的所有虚拟地址，对应于一个 1GiB 的大页； > - 如果使用了二级页索引就停下来，则它可以涵盖虚拟页号的高 18 位为某一固定值的所有虚拟地址，对应于一个 2MiB 的大页； > - 如果使用了所有三级页索引才停下来，它可以涵盖虚拟页号的高 27 位为某一个固定值的所有虚拟地址，自然也就对应于一个大小为 4KiB 的虚拟页面。 这里的 一级索引 在使用上似乎用于映射 根页表（第三级页表）的页表项（不知道有没有理解出错）...
另外，我发现了似乎比较矛盾的地方： 1. [注解中大页部分](http://rcore-os.cn/rCore-Tutorial-Book-v3/chapter4/3sv39-implementation-1.html#id7:~:text=%E5%9C%A8%20SV39%20%E4%B8%AD,%E8%99%9A%E6%8B%9F%E9%A1%B5%E9%9D%A2%E3%80%82) 2. [SV39 地址转换过程部分](http://rcore-os.cn/rCore-Tutorial-Book-v3/chapter4/3sv39-implementation-1.html#id7:~:text=%E5%9C%A8%20SV39%20%E6%A8%A1%E5%BC%8F,%E3%80%82) 前后对一级索引的解释相矛盾了：前者说一级索引是虚拟页号高九位；后者说一级索引为 vpn 后九位
set_timer 函数是对 mtimecmp 的更新，是对 M 态的 CSR 进行操作，假如进程正处于内核态，此时发生的时钟中断应该是来自M态的，处于内核态的进程没法屏蔽这个时钟中断吧？
> set_timer 函数是对 mtimecmp 的更新，是对 M 态的 CSR 进行操作，假如进程正处于内核态，此时发生的时钟中断应该是来自M态的，处于内核态的进程没法屏蔽这个时钟中断吧？ 不过，根据 rustsbi 的文档，set_timer 是设置 S 态的时钟..... > fn [set_timer](https://docs.rs/rustsbi/latest/rustsbi/trait.Timer.html#tymethod.set_timer)(&self, stime_value: u64) > Programs the clock for next event after stime_value time....