Merge branch 'rcore-os:master' into master

Author: Lfan-ke

source/_posts/2023秋冬季开源操作系统训练营第三阶段总结报告-明扬.md

@@ -0,0 +1,16 @@
+---
+title: 2024秋冬训练营第3阶段总结-明扬
+date: 2024-12-06 17:00:00
+categories:
+    - 2024秋冬季开源操作系统训练营 
+tags:
+    - author:mingyang
+    - repo:https://github.com/mingyang91
+---
+
+# 第三阶段总结
+第三阶段难度与前两阶段相比难度上升不少.
+课程框架代码质量也是非常高的, 适配了常见CPU指令集, 是可以应用到实际生产系统中的代码框架.
+尽管完成实验所需要的代码量不高, 但对题目和计算机结构的理解要求提高了非常多. 本阶段课程结束后我学到了 unikernel 模式和 Hypervisor 工作原理, 受益匪浅.
+还参加了三阶段的 Allocator 排名竞赛, 锻炼了自己的意识和眼界.
+四阶段已经选择了异步操作系统课题, 希望自己继续努力, 完成所有课程.

source/_posts/2024 秋冬季开源操作系统训练营第三阶段总结报告-戴志强.md

@@ -0,0 +1,151 @@
+---
+title:  2024 秋冬季开源操作系统训练营第三阶段总结报告-戴志强
+date: 2024-12-2 22:20:00
+tags:
+    - author:Heliosly
+---
+
+# 2024 秋冬季开源操作系统训练营 项目基础阶段
+
+---
+
+## **进度情况：**
+
+由于忙于区域赛和大创申请书，三阶段的时间并不充足，作业仅仅做到hypervisor前的部分，仅阅读了部分源码。
+
+## Unikernel基础与框架
+
+### 题1
+
+只需要将
+
+`println!("[WithColor]: !");`
+
+改为
+`println!("\x1b[33m[WithColor]: Hello, Arceos!\x1b[0m");`
+
+可以打出黄色字体。
+
+### 题2
+
+要求实现HashMap，并且提供随机数，我还没办法理解随机数和HashMap的关系，所以写了一个简单的HashMap
+
+```rust
+struct KeyValue<K, V> {
+    key: K,
+    value: V,
+}
+pub struct HashMap<K, V> {
+    buckets: Vec<Vec<Option<KeyValue<K, V>>>>,  
+}
+fn hash(&self, key: &K) -> usize {
+    let key_ptr = key as *const _ as usize;
+    key_ptr % self.buckets.len()
+}
+```
+
+## Unikernel地址空间与分页、多任务支持(协作式)
+
+**题目要求：**
+
+只能修改modules/bump_allocator组件的实现，支持bump内存分配算法。不能改其它部分。
+
+Bumpallocator 结构体
+
+```rust
+pub struct EarlyAllocator<const PAGE_SIZE: usize> {
+heap_start: usize,
+heap_end: usize,
+next: usize,
+allocations: usize,
+page_pos: usize,
+}
+```
+
+Base allocator需要的init 与 add_memory
+
+```rust
+
+impl<const PAGE_SIZE: usize> BaseAllocator for EarlyAllocator<PAGE_SIZE> {
+    fn add_memory(&mut self, start: usize, size: usize) -> AllocResult {
+        
+        self.heap_end = start + size;
+        Ok(())
+    }
+
+    fn init(&mut self, start: usize, size: usize) {
+        self.heap_start = start;
+        self.heap_end = size + self.heap_start;
+        self.next = self.heap_start;
+    }
+    
+}
+```
+
+PageAllocator因没有dealloc所以未实现
+
+```rust
+fn alloc_pages(&mut self, num_pages: usize, align_pow2: usize) -> AllocResult<usize> {
+let align_mask = (1 << align_pow2) - 1;
+let required_size = num_pages * PAGE_SIZE;
+let aligned_pos = (self.page_pos + align_mask) & !align_mask;
+let allocated_pages = aligned_pos;
+self.page_pos = aligned_pos + required_size;
+Ok(allocated_pages)
+}
+```
+
+ByteAllocator
+
+```rust
+impl<const PAGE_SIZE:usize> ByteAllocator for EarlyAllocator<PAGE_SIZE>{
+    fn alloc(&mut self, layout: Layout) -> AllocResult<NonNull<u8>> {
+        let alloc_start = self.next;
+        self.next = alloc_start + layout.size();
+        self.allocations += 1;
+        Ok(unsafe { NonNull::new_unchecked(alloc_start as *mut u8) })
+
+    }
+    fn dealloc(&mut self, pos: NonNull<u8>, layout: Layout) {
+        self.allocations -= 1;
+        if self.allocations == 0 {
+            self.next = self.heap_start;
+    }
+    }
+```
+
+## 从Unikernel到宏内核
+
+**题目要求：**
+
+需要补全缺页加载代码。
+
+观察m1.0.0 task中代码，发现用 current().task_ext()可以得到TaskExt，然后TaskExt中包含一个AddSpace 结构体，该结构体实现了处理缺页加载的方法。于是按照该思路需要补充的代码如下
+
+```rust
+use axhal::{mem::VirtAddr,paging::MappingFlags};
+use axhal::trap::{register_trap_handler,PAGE_FAULT};
+#[register_trap_handler(PAGE_FAULT)]
+fn handle_page_fault(vaddr: VirtAddr, access_flags: MappingFlags, is_user: bool) -> bool {
+    if is_user {
+        if !axtask::current()
+            .task_ext()
+            .aspace
+            .lock()
+            .handle_page_fault(vaddr, access_flags)
+        {
+            ax_println!("handle_page_fault failed, vaddr={:#x}", vaddr);
+            axtask::exit(-1);
+        } else {
+            true
+        }
+        
+    } 
+    else{
+        false
+    }
+    
+}
+```
+
+**感想**：与 Rcore 相比，似乎 ArceOS显得更加复杂，因其为了实现模块之间的兼容性，采用了多层的封装、抽象和隔离机制。然而，从我的编程体验来看，从某个特定模块的视角来看，阅读 ArceOS 的代码反而比 Rcore 更加清晰。降低了局部代码阅读难度，是值得学习的编码习惯。同时，ArceOS 的课程内容十分丰富，极大地拓宽了我的操作系统视野。

source/_posts/2024 秋冬季开源操作系统训练营第四阶段总结-卓堂越.md

@@ -0,0 +1,56 @@
+title:2024 秋冬季开源操作系统训练营第四阶段总结-卓堂越
+date: 2024-12-22 12：48:00
+categories:
+    - report
+tags:
+    - author: nusakom
+    - repo: https://github.com/nusakom/OPENcv.git
+---
+
+## 从小白到操作系统开发者：我的训练营历程与成长
+
+参加训练营已经快一年了，回顾这段时间的学习与实践，感觉收获满满，成长也非常明显。虽然过程中经历了不少挑战，但我从中学到了很多，也更加明白了自己未来的目标和方向。
+
+### 从初识RTOS和操作系统
+
+从今年刚刚开始接触开源操作系统训练营，感觉开辟了一片新的天地在训练营的第一阶段，我还是一个对RTOS（实时操作系统）了解甚少的“小白”。当时，我的理解仅限于知道 **FreeRTOS** 是什么，而对于操作系统的具体结构和工作原理几乎没有任何概念。然而，通过这段时间的学习，我开始接触并逐步理解操作系统的基本组成部分，像是内核、调度、进程管理等。这个阶段的学习让我明白了操作系统不仅仅是运行应用程序的基础，更是硬件和软件之间的重要桥梁。
+
+#### 网络问题与任务挑战
+
+不过，学习的过程并不是一帆风顺的。由于网络不稳定，很多简单的任务总是上传不了，这让我有时感到非常沮丧。更有一次，我因为任务时间限制和一些技术难题，没能在结课期间按时完成所有的任务。这些问题让我认识到，技术的实现不仅仅依赖于个人的能力，还需要更好的时间管理和稳定的技术环境支持。
+
+### 深入探索异步编程与Python适配
+
+进入训练营的第二阶段后，任务的难度逐步增加。我选择了一个相对较简单的方向，与其他小伙伴们一起研究 **异步编程**。虽然这与我之前的经验较为接近，但在实际实现过程中，我还是遇到了不少挑战，尤其是在理解异步编程模型时。
+
+然而，通过逐步的实现，我不仅加深了对异步编程的理解，还接触了Python适配的相关知识。实际上，这个阶段让我学到了很多之前没有涉及的技术，这些新知识极大地丰富了我的技术栈，也让我对未来的技术方向更加清晰。
+
+### Python与OpenCV的结合
+
+尽管我没有完全按预期完成所有任务，但这个阶段让我深入思考了自己的学习方法。我曾经盲目追求高难度的任务，而忽略了任务的实际意义和自己的能力匹配。因此，在这个阶段，我主动选择了一个相对简单的任务——**OpenCV** 的相关实践。尽管我最终未能在 **Starry** 上完成OpenCV的测例，但这个过程让我更加明白了如何进行项目规划和任务分配。
+
+在这阶段，我还负责了Python与OpenCV的结合，进行了一些与图像处理相关的实验和项目。通过这些实践，我深入了解了Python的图像处理能力，尤其是OpenCV库在计算机视觉中的应用。例如，如何使用OpenCV进行图像读取、处理和展示，这些操作帮助我了解了计算机如何通过视觉来感知和分析信息。
+
+#### 实现Python3.11的syscall系统调用
+
+作为实习任务的一部分，我参与了分析和实现支持 **Python3.11** 程序的 **syscall** 系统调用，尤其是在 **ArceOS/Starry** 系统中，逐步完善Python程序所依赖的系统调用。具体来说，这个过程涉及了用户态程序的交叉编译、依赖库的交叉编译、以及系统模拟器 **Qemu** 中的实验。
+
+1. **交叉编译Python程序**：首先，我需要交叉编译 **Python3.11**，以支持 **aarch64** 架构。这包括了编译所需的依赖库（如 **libffi**、**zlib**、**libuuid** 和 **xz** 等），并且每个依赖库都必须交叉编译，以保证在目标架构上能够正常运行。
+
+2. **Qemu模拟环境**：为了测试在交叉编译后的Python程序，我在 **Qemu** 模拟环境中运行了一个 **aarch64** 架构的 **Alpine Linux**，并在其中加载了交叉编译生成的Python库。通过这种方式，我能够测试并调试系统调用，确保它们能够在模拟器中正常执行。
+
+3. **系统调用分析**：我使用 **strace** 工具来统计Python程序所使用的所有系统调用，并分析它们在不同架构下的表现。通过这个过程，我深入了解了 **syscall** 的工作机制，并能够在实际操作系统中正确实现这些调用。
+
+通过这个任务，我不仅加深了对操作系统内核和系统调用机制的理解，还在实践中学会了如何处理复杂的交叉编译任务。
+
+### 未来的目标--操作系统与编译器
+
+回顾这一年的学习，我不仅了解了操作系统的基本原理，还在逐步实现的过程中积累了不少经验。尤其是从一个仅仅知道FreeRTOS的小白，到如今能够理解操作系统结构的程度，我感到自己有了明显的进步。
+
+最令我兴奋的是，未来我希望能够在自己写的操作系统上运行自己开发的编译器。这是我一直以来的梦想，虽然这需要我不断努力和学习，但我相信，通过这段时间的积累，我已经打下了坚实的基础。
+
+### 总结
+
+参加训练营的这一年里，我收获了很多，不仅有热心的助教和同学的帮助，还有机会接触到多种新技术和工具。虽然遇到了一些困难，但这些都成为了我成长的动力。我相信，未来我会继续沿着这个方向前行，实现自己在操作系统和编译器领域的梦想。
+
+---

source/_posts/2024-秋冬季-rcore阶段二blog-李彦泽.md

@@ -0,0 +1,35 @@
+---
+title: 2024 秋冬季 rcore阶段二blog  李彦泽
+date: 2024-11-08 19:33:49
+tags:
+---
+
+# 第一阶段
+
+补充第一阶段的内容:主要就是学习rust的使用,基本上问题都能够解决
+
+在阶段二让我对操作系统和rust有了更加深刻的理解
+
+## 操作系统部分
+
+其实我是有linux内核和驱动的开发经验的，所以对虚拟地址、物理地址、页表、等等知识都是有接触的，但是主要还是停留在书本或者内核提供的api，这五次作业，让我用rust这门最开始接触的语言来实现底层，也还是难度不小。
+
+最开始的页表啊、映射啊、以及一些环境搭建还有git使用对我来说基本没有难度，但是到了第四个lab和第五个lab就开始难了。
+
+文件系统：这个本身我对其就没有太清楚的了解过内部结构，只是会用，这次lab4的作业，强制我要去看源码实现，对超级区块，以及bitmap管理分配的索引，以及bitmap管理内容区块，再到系统层面通过OSInode来管理每个文件的inode，以及管理到物理磁盘上的inode，以及文件名啥的相互联系，让我从底层的磁盘到上层OS的管理链路有了比较清晰的认识，并且对rust的使用有了更加深刻的理解(没错，特指生命周期，和mut ref),因为这两个没少出现借用的问题。
+
+死锁检测:这个部分也是耗时很长，其实我认为这部分的理解不难，因为我很早就接触了锁、信号量这些，我觉得这部分最难的在于调试。由于是并发编程，遇到的情况千奇百怪，以及难以定位。所以我写了很多的log，并且以非常人性化的输出来查看，虽然这部分耗时比较久，但是打好log对后续的开发是如虎添翼。也不会有陷入log中无法自拔的问题。并且通过实现了这个算法，算是开辟了新的知识点，以前从来没有想到还能死锁检测。
+
+## 对同学的建议
+
+总的来说难度不小，并且其实资料是比较有限的(对于无从下手的新手来说),所以如果卡关了还是要多去搜索资料，以及看源码(这个很重要)，去看具体的实现，以及画流程图和结构体之间的关系图，以及标注重要的api(找到合适的api可以事半功倍)
+
+## 对项目建议
+
+总的来说操作系统的重点都有涉及，知识面还是很充足的!!
+
+但是在编写过程中明显感觉到由于前向兼容导致测试用例的编译越到后期越慢，每次run光编译就会花费一分钟，其实可以优化makefile来单独编译某些测例来减少测试开发的时间。
+
+以及最后两个lab难度上升有点大，并且文章 中是对功能的描述居多(很多对于实验有用的点会被淹没在其中)虽然在边做lab边反复查看资料时可以发现，但是对于没有接触过的同学可能很多api看过就没印象了，在后续做lab中也找不到，所以可以适当增加一下强调或者提示，来减少难度增加坡度。
+
+最后还可以收集一下大家的调试方法，这样对于后续对debug无从下手的同学也有参考意义。