update

Author: Docter-R

os/Makefile

@@ -22,7 +22,7 @@ KERNEL_ENTRY_PA := 0x80200000
 OBJDUMP := rust-objdump --arch-name=riscv64
 OBJCOPY := rust-objcopy --binary-architecture=riscv64
 
-CHAPTER ?= $(shell git rev-parse --abbrev-ref HEAD | sed -E 's/ch([0-9])/\1/')
+CHAPTER ?= $(shell git rev-parse --abbrev-ref HEAD | sed -E 's/ch()/\1/')
 TEST ?= $(CHAPTER)
 BASE ?= 1
 

os/src/trap/mod.rs

@@ -41,14 +41,17 @@ pub fn trap_handler(cx: &mut TrapContext) -> &mut TrapContext {
     let scause = scause::read(); // get trap cause
     let stval = stval::read(); // get extra value
     match scause.cause() {
+        //  处理系统调用 (UserEnvCall)
         Trap::Exception(Exception::UserEnvCall) => {
             cx.sepc += 4;
             cx.x[10] = syscall(cx.x[17], [cx.x[10], cx.x[11], cx.x[12]]) as usize;
         }
+        // 处理访存错误 (StoreFault / StorePageFault)
         Trap::Exception(Exception::StoreFault) | Trap::Exception(Exception::StorePageFault) => {
             println!("[kernel] PageFault in application, kernel killed it.");
             run_next_app();
         }
+        // 处理非法指令 (IllegalInstruction)
         Trap::Exception(Exception::IllegalInstruction) => {
             println!("[kernel] IllegalInstruction in application, kernel killed it.");
             run_next_app();

reports/Lab 3.md

@@ -0,0 +1,105 @@
+# `Lab 3`
+
+## 荣誉准则
+
+1. 在完成本次实验的过程（含此前学习的过程）中，我曾分别与 **以下各位** 就（与本次实验相关的）以下方面做过交流，还在代码中对应的位置以注释形式记录了具体的交流对象及内容：
+
+   > 无
+
+2. 此外，我也参考了 **以下资料** ，还在代码中对应的位置以注释形式记录了具体的参考来源及内容：
+
+   > 无
+
+3. 我独立完成了本次实验除以上方面之外的所有工作，包括代码与文档。 我清楚地知道，从以上方面获得的信息在一定程度上降低了实验难度，可能会影响起评分。
+
+4. 我从未使用过他人的代码，不管是原封不动地复制，还是经过了某些等价转换。 我未曾也不会向他人（含此后各届同学）复制或公开我的实验代码，我有义务妥善保管好它们。 我提交至本实验的评测系统的代码，均无意于破坏或妨碍任何计算机系统的正常运转。 我清楚地知道，以上情况均为本课程纪律所禁止，若违反，对应的实验成绩将按“-100”分计。
+
+------
+
+## 问答题解答
+
+### 问题1：实际情况是轮到 p1 执行吗？为什么？
+
+不是。实际情况是 p2 会再次执行。
+
+**原因**：
+- p1.stride = 255，p2.stride = 250
+- p2 执行一个时间片后，stride 增加 pass=10，得到 250+10=260
+- 由于使用 8bit 无符号整数，260 会溢出变成 4（260 mod 256 = 4）
+- 此时 p1.stride = 255，p2.stride = 4
+- 由于 4 < 255，所以 p2 会再次被执行，而不是 p1
+
+### 问题2：为什么 STRIDE_MAX – STRIDE_MIN <= BigStride / 2？
+
+**原因**：
+- 进程优先级 ≥ 2，所以每个进程的 pass = BigStride / priority ≤ BigStride / 2
+- 当某个进程的 stride 落后其他进程超过 BigStride / 2 时，它会被立即调度
+- 因为它的 stride 最小，会被调度器选中
+- 调度后它的 stride 增加 pass ≤ BigStride / 2，仍然不会超过其他进程的 stride 超过 BigStride / 2
+- 因此，所有进程的 stride 差值始终不会超过 BigStride / 2
+
+### 问题3：补全比较器代码
+
+```rust
+use core::cmp::Ordering;
+
+const BIG_STRIDE: u64 = 255; // 假设 BigStride 为 255
+
+struct Stride(u64);
+
+impl PartialOrd for Stride {
+    fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
+        let a = self.0;
+        let b = other.0;
+        let diff = (a as i16).wrapping_sub(b as i16);
+        
+        if diff > 0 {
+            // a > b
+            if diff <= (BIG_STRIDE / 2) as i16 {
+                Some(Ordering::Greater)
+            } else {
+                // 差值过大，说明 b 溢出了，实际 b > a
+                Some(Ordering::Less)
+            }
+        } else {
+            // a < b
+            if (-diff) <= (BIG_STRIDE / 2) as i16 {
+                Some(Ordering::Less)
+            } else {
+                // 差值过大，说明 a 溢出了，实际 a > b
+                Some(Ordering::Greater)
+            }
+        }
+    }
+}
+
+impl PartialEq for Stride {
+    fn eq(&self, other: &Self) -> bool {
+        false
+    }
+}
+```
+
+**原理**：
+- 利用有符号整数的环绕减法计算差值
+- 如果差值的绝对值 ≤ BigStride / 2，说明没有跨越溢出边界，直接比较
+- 如果差值的绝对值 > BigStride / 2，说明跨越了溢出边界，实际大小关系与表面相反
+
+## 功能总结
+
+我实现了两个系统调用：
+
+1. **`sys_set_priority(prio: isize) -> isize`**：
+   - 设置当前进程的优先级
+   - 优先级必须 ≥ 2，否则返回 -1
+   - 设置成功后重新计算步长 pass = BIG_STRIDE / priority
+   - 返回设置的优先级
+
+2. **`sys_spawn(path: *const u8) -> isize`**：
+   - 创建新的子进程执行指定程序
+   - 不复制父进程地址空间，直接加载目标程序
+   - 建立正确的父子进程关系
+   - 设置子进程返回值为 0
+   - 成功返回子进程 PID，失败返回 -1
+
+同时实现了 stride 调度算法，为每个进程维护 stride、pass、priority 字段，调度时选择 stride 最小的进程，确保高优先级进程获得更多 CPU 时间。

reports/Lab 4.md

@@ -0,0 +1,96 @@
+# Lab 4
+
+## 荣誉准则
+
+1. 在完成本次实验的过程（含此前学习的过程）中，我曾分别与 **以下各位** 就（与本次实验相关的）以下方面做过交流，还在代码中对应的位置以注释形式记录了具体的交流对象及内容：
+
+   > 无
+
+2. 此外，我也参考了 **以下资料** ，还在代码中对应的位置以注释形式记录了具体的参考来源及内容：
+
+   > 无
+
+3. 我独立完成了本次实验除以上方面之外的所有工作，包括代码与文档。 我清楚地知道，从以上方面获得的信息在一定程度上降低了实验难度，可能会影响起评分。
+
+4. 我从未使用过他人的代码，不管是原封不动地复制，还是经过了某些等价转换。 我未曾也不会向他人（含此后各届同学）复制或公开我的实验代码，我有义务妥善保管好它们。 我提交至本实验的评测系统的代码，均无意于破坏或妨碍任何计算机系统的正常运转。 我清楚地知道，以上情况均为本课程纪律所禁止，若违反，对应的实验成绩将按“-100”分计。
+
+------
+
+## 问答题解答
+
+## ch6:
+
+### 1. 在我们的easy-fs中，root inode起着什么作用？如果root inode中的内容损坏了，会发生什么？
+
+答：
+
+Root Inode 在 Easy-FS 中的作用：
+
+1. **文件系统的入口点**
+
+- **根目录**：Root inode 代表文件系统的根目录 `/`
+- **起点**：所有文件和目录的查找都从 root inode 开始
+- **目录结构**：包含文件系统的初始目录项，指向其他文件和子目录
+
+2. **持久化存储**
+
+- 在 Easy-FS 中，root inode 通过静态变量持久化
+
+如果 Root Inode 损坏的后果
+
+1. **灾难性的数据丢失**
+
+- **完全无法访问**：整个文件系统变得不可访问
+- **连锁反应**：由于所有路径解析都从 root inode 开始，损坏会导致所有操作失败
+
+2. **具体故障表现**（如：元数据损坏、目录项损坏）
+
+### 2.介绍我完成的代码
+
+我实现了三个文件系统相关的系统调用：
+
+**fstat**：获取文件状态信息。通过文件描述符找到对应的文件，返回文件的元数据，包括设备ID、inode号、文件类型和硬链接计数等。
+
+**linkat**：创建硬链接。接受原文件名和新文件名作为参数，在文件系统中创建指向同一inode的硬链接，同时增加原文件的链接计数。
+
+**unlinkat**：删除文件链接。删除指定路径的文件目录项，减少文件的硬链接计数。当链接数降为0时，回收文件占用的数据块资源。
+
+这些实现基于Easy-FS文件系统，支持基本的文件链接管理和状态查询功能，为应用程序提供了POSIX兼容的文件操作接口。
+
+## ch7:
+
+### 1. 使用 Pipe 的实际应用例子
+
+在 Linux terminal 中，我们经常使用管道将多个命令连接起来。例如统计文件行数：
+
+```bash
+cat file.txt | wc -l
+```
+
+这里：
+- `cat file.txt` 输出文件内容到标准输出
+- 管道 `|` 将 `cat` 的输出重定向为 `wc -l` 的输入
+- `wc -l` 统计输入的行数并输出结果
+
+### 2. 如果需要在多个进程间互相通信，则需要为每一对进程建立一个管道，非常繁琐，请设计一个更易用的多进程通信机制。
+
+**设计：基于命名的消息队列系统**
+
+1. **命名消息队列**：
+   - 每个队列有唯一名称，进程通过名称访问
+   - 支持多个生产者和消费者
+
+2. **发布-订阅模式**：
+   - 进程可以订阅感兴趣的消息类型
+   - 消息按主题分类，自动路由到订阅者
+
+3. **共享内存区域**：
+   - 建立共享内存段用于高效数据传输
+   - 配合信号量进行同步控制
+
+4. **中央消息路由器**：
+   - 一个专门的消息路由进程
+   - 负责消息的接收、分类和分发
+   - 提供消息持久化和确认机制
+
+这种设计比点对点管道更灵活，支持一对多、多对多通信模式，大大简化了多进程间的通信复杂度。

reports/Lab 5.md

@@ -0,0 +1,70 @@
+# `Lab 5
+
+## 荣誉准则
+
+1. 在完成本次实验的过程（含此前学习的过程）中，我曾分别与 **以下各位** 就（与本次实验相关的）以下方面做过交流，还在代码中对应的位置以注释形式记录了具体的交流对象及内容：
+
+   > 无
+
+2. 此外，我也参考了 **以下资料** ，还在代码中对应的位置以注释形式记录了具体的参考来源及内容：
+
+   > 无
+
+3. 我独立完成了本次实验除以上方面之外的所有工作，包括代码与文档。 我清楚地知道，从以上方面获得的信息在一定程度上降低了实验难度，可能会影响起评分。
+
+4. 我从未使用过他人的代码，不管是原封不动地复制，还是经过了某些等价转换。 我未曾也不会向他人（含此后各届同学）复制或公开我的实验代码，我有义务妥善保管好它们。 我提交至本实验的评测系统的代码，均无意于破坏或妨碍任何计算机系统的正常运转。 我清楚地知道，以上情况均为本课程纪律所禁止，若违反，对应的实验成绩将按“-100”分计。
+
+------
+
+## 问答题解答
+
+## 1. 进程退出时的资源回收
+
+**需要回收的资源包括：**
+
+1. **线程控制块 (TaskControlBlock)**：所有子线程的TCB
+2. **内核栈**：每个线程的内核栈空间
+3. **用户栈**：每个线程的用户栈空间  
+4. **虚拟内存资源**：进程的地址空间、页表等
+5. **文件描述符**：进程打开的文件资源
+6. **同步原语**：进程创建的mutex、semaphore等
+7. **死锁检测状态**：进程的死锁检测器相关数据结构
+
+**TaskControlBlock可能被引用的位置及回收情况：**
+
+1. **进程的线程列表中**：必须回收，因为这是进程直接管理的资源
+2. **就绪队列中**：必须回收，否则会导致调度器访问无效的TCB
+3. **等待队列中**（mutex、semaphore等）：必须回收，否则唤醒时会访问无效TCB
+4. **条件变量等待队列中**：必须回收
+5. **父子进程关系中**：必须回收，避免孤儿进程
+6. **定时器队列中**：必须回收，避免定时器触发时访问无效TCB
+
+**回收原因**：这些引用如果不及时回收，会导致use-after-free、内存泄漏、系统状态不一致等问题。
+
+## 2. 两种Mutex实现的区别及问题
+
+**主要区别：**
+
+1. **锁获取逻辑不同**：
+   - Mutex1：使用循环重试，确保被唤醒后重新检查锁状态
+   - Mutex2：无循环，被唤醒后直接认为获得锁
+
+2. **锁释放逻辑不同**：
+   - Mutex1：总是将locked置为false，然后唤醒等待线程
+   - Mutex2：只有在等待队列为空时才将locked置为false
+
+**可能导致的问题：**
+
+1. **虚假唤醒问题**：Mutex2在被唤醒后没有重新检查锁状态，如果存在虚假唤醒或多个线程同时被唤醒，可能导致多个线程同时进入临界区，破坏互斥性。
+
+2. **锁状态不一致**：Mutex2在唤醒等待线程时没有释放锁标记，被唤醒的线程看到的锁状态仍然是locked=true，但实际上锁应该已经释放。
+
+3. **公平性问题**：Mutex1通过循环确保先到先服务，Mutex2可能产生饥饿现象。
+
+4. **死锁风险**：在Mutex2中，如果唤醒的线程因为某种原因没有运行，锁状态可能一直保持locked=true，导致其他线程无法获取锁。
+
+## 3. 功能实现总结
+
+我实现了一个基于银行家算法的死锁检测机制。该机制将mutex和semaphore抽象为资源类，维护Available、Allocation、Need三个核心矩阵。在资源申请时执行安全状态检查，如果检测到潜在死锁则拒绝请求并返回特定错误码。通过新的系统调用允许进程按需启用/禁用死锁检测功能，保持向后兼容性。实现涉及死锁检测器数据结构、系统调用包装、资源状态管理等模块。
+
+完成本次实验大约用了6小时，主要时间花费在理解银行家算法原理、设计数据结构集成方案、调试线程ID获取和资源状态同步等问题上。