实验小项目招新：基于unikernel底座且支持Linux App的组件化宏内核

[chyyuu]

小任务：

注：2025春夏季OS训练营四阶段同学，请结合自己的兴趣和时间，先选择你觉得适合你的一个小任务（建议从简单的入手），并告知相关助教和老师。

2025OS训练营后续的暑期实践小任务

• 在starry-next中支持vdso功能

2025OS训练营小任务

• 给OS训练营的内核组件crate写crate文档和测例，升级rust工具链2025-05-20-nightly，尝试进一步改进crate，使其具有可提交到crates.io网站上的质量，从而帮助更多同学能方便使用各种内核组件，组合出各种形态的内核。
• 给三阶段的oscamp项目添加github CI/CD支持 @yjymosheng
• 扩展三阶段的oscamp项目添加新的unikernel/monolithickernel/hypevisor的tutor例子
• 合并arceos-org的oscamp项目与learningos的oscamp为一个统一的oscamp
• 升级三阶段的oscamp项目，替换其repo中的arceos，直接采用主线的arceos
• 升级三阶段的oscamp项目，替换其repo中的arceos，直接采用OS比赛的arceos
• 升级三阶段的oscamp项目，支持x86-64
• 升级三阶段的oscamp项目，支持aarch64 @879650736
• 升级三阶段的oscamp项目，支持loongarch64
• 改进starry-next tutorial book(writing)文档
• 升级rust工具链2025-0520：支持starry-next的底层arceos ，可学习参考arceos-org的arceos的commit @MF-B @AMIRIOX @listline @elebirds @aluojibuzhu
  1. 学习：fork https://github.com/arceos-org/arceos
  2. 学习：clone到本地，在arceos目录下执行"make run"，如果能看到最后一行的“Hello, world!”，表明arceos可以用rust 2025-05-20-nightly正常编译并运行
  3. 学习：分析 git commit f4428b49970c9b4d871d4dd37cf3e0f1cc200bb1的具体内容, 即学习 arceos如何修改，修改了哪些文件
  4. 改进：clone https://github.com/oscomp/arceos 到本地，根据3的学习，完成类似的修改，通过“make run”，通过acreos的CI。
  5. 改进：进一步改进相关组件，确保升级工具链后的arceos能支持starry-next正常通过starry-next的CI。
• 完成与上游最新开发的arceos的同步，如分析升级工具链后的宏内核 arceos，理解它与上游 arceos的区别，理解并同步上游 arceos的最新进展，即https://github.com/arceos-org/arceos/commits/new-axhal/ 中的 Commit 63c5a67 合并到自己的宏内核 arceos中，并改进可能的其他组件，确保新的arceos和starry-next能依然通过CI
• 给上游最新开发的arceos提交系列PR，如分析当前的升级工具链后的宏内核 arceos 相对与上游arceos的更新，理解更新，形成PR分析文档和PR，给上游最新开发的arceos提交系列合乎CI要求的PR
• 改进支持starry-next的底层arceos ，能够与支持组件化axvisor hypervisor的底层arceos合并为一个统一的arceos repo @elebirds
• 把上一步任务形成的统一的新的arceos进行整理，把整个更新按步骤，逐步拆分为n个有意义的小PR，逐步合并到上游arceos中
• 改进/封装ext4（如lwext4等）文件系统crate，改进对应的CI/CD
• 改进/封装tcp/ip(如lwip等）协议栈crate，改进对应的CI/CD
  • 参考：组件化OS--aceros的改进：代码：https://github.com/Centaurus99/arceos-lwip 文档： https://github.com/Centaurus99/arceos-lwip/tree/main/reports
  • 参考：组件化OS--aceros的改进: udp与dns smoltcp改进：代码： https://github.com/reflyable/arceos-udp 文档：https://github.com/reflyable/arceos-udp/tree/report/report
• 改进/封装USB协议栈(如cherryUSB等)crate，改进对应的CI/CD
  • https://github.com/cherry-embedded/CherryUSB
  • https://cherryusb.readthedocs.io/zh-cn/latest/index.html
  • https://github.com/HaoboGu/cherryusb-rs：初步尝试
• 改进同步互斥相关crate，改进对应的CI/CD
• 改进多核支持相关crate，改进对应的CI/CD
• 改进实时调度相关crate，改进对应的CI/CD
• 改进arceos\starry-next中的某个crate，实现/改进对应的CI/CD
• 改进starry-next，增加starry-next的进程/内存/同步互斥/文件系统/网络协议栈的syscall，添加与此相关的测例，通过比赛测例
• 重构改进各种arceos/starry-next中的内部耦合或相关独立的crates，改进对应的CI/CD
• 支持gcc应用
• 支持git应用
• 支持syzkaller应用
• 支持各种相对复杂的Linux应用
• 扩展启动和相关驱动支持，支持树莓派开发板
• 扩展启动和相关驱动支持，支持飞腾派开发板
• 扩展启动和相关驱动支持，支持龙芯开发板
• 扩展启动和相关驱动支持，支持各种RV开发板
• 扩展启动和相关驱动支持，支持x86台式机或笔记本电脑

欢迎提出自己感兴趣的新的小任务，请联系 请联系我 yuchen AT tsinghua.edu.cn OR 微信 id chyyuu @chyyuu @Azure-stars

相关网址：

• 2025全国大学生OS比赛内核赛道OS参考-starry-next
• 2025春夏季开源OS训练营三阶段组件化内核设计与实现实习项目
• 2025春夏季开源OS训练营四阶段组件化宏内核实习项目
• 2025全国大学生OS比赛内核赛道的相关测例

开发日志：

• 开源OS训练营的学员总结报告
• starry-next tutorial book(writing)
• 2025年春部分在校生的starry-next开发日志

参考资料：

• 2021-2025全国大学生OS比赛内核赛道的优秀比赛作品(开源)
• 2021-2025全国大学生OS比赛内核赛道的各类软件参考资源
• 各种基于Rust的OS/hypervisor列表
• 与linux syscall/POSIX/API等相关的分析/新内核设计等方面的论文：注：偏研究探索

如有兴趣一起来探索，承担小任务。请联系我 yuchen AT tsinghua.edu.cn OR 微信 id chyyuu

[chyyuu]

几位(cjy,wyd,zyj, lyf)关于syscall的分工如何划分？

[chyyuu]

关于process/thread control block的设计，目前是否已经确定了？在哪些方面还没确定？

[chunchunyd]

@Azure-stars 我把文件系统添加到你的进程里时遇到了一个问题，ArceOS的依赖关系如下图，如果要在axtask里调用axfs里的结构和接口的话，会出现一条axfs->axsync->axtask->axfs的循环依赖。

graph TD;
	axalloc
	axconfig
	axdisplay
	axdriver
	axfs
	axhal
	axlog
	axnet
	axruntime
	axsync
	axtask
	
	axsync-->axdisplay
	axdriver-->axdisplay
	
	axhal-->axdriver
	axalloc-->axdriver
	axconfig-->axdriver

	axdriver-->axfs
	axsync-->axfs
	axtask-.dev.->axfs
	
	axconfig-->axhal
	axalloc-->axhal
	axlog-->axhal
	
	axhal-->axnet
	axsync-->axnet
	axtask-->axnet
	axdriver-->axnet
	
	axalloc-->axruntime
	axconfig-->axruntime
	axdriver-->axruntime
	axhal-->axruntime
	axlog-->axruntime
	axfs-->axruntime
	axnet-->axruntime
	axdisplay-->axruntime
	axtask-->axruntime
	
	axtask-->axsync
	
	axalloc-->axtask
	axhal-->axtask
	axconfig-->axtask
	axlog-->axtask

Loading

[Azure-stars]

关于依赖关系，在一开始我加入进程控制时，由于主线程结束需要由进程来进行共享资源的回收，而进程的数据结构中又包含了对线程的引用，导致若将进程和线程简单分开会出现依赖成环的关系。所以初始阶段我比较暴力地将进程和线程放在了同一个模块。

而这也导致了进程加入文件描述符表后会出现依赖成环的关系。

我觉得当前的一个解决方式是将进程单独独立为一个模块。之后的依赖关系应当是axprocess依赖于axfs，而axfs依赖于axsync，再依赖于axtask。

[chunchunyd]

主线程结束需要由进程来进行共享资源的回收，而进程的数据结构中又包含了对线程的引用，导致若将进程和线程简单分开会出现依赖成环的关系

而且即使不考虑线程结束时的资源回收问题，线程控制块中本身也应该有一个指向所属进程的弱指针，这样不是还是需要把进程控制块类型引入进来吗？这个依赖问题你有解决的思路了吗？

[Azure-stars]

我现在已经完成了process和task模块的解耦，当前我的代码中依赖关系如下：

graph TD;
axsync-->axdisplay
axdriver-->axdisplay

axhal-->axdriver
axalloc-->axdriver
axconfig-->axdriver

axdriver-->axfs
axsync-->axfs
axtask-.dev.->axfs

axconfig-->axhal
axalloc-->axhal
axlog-->axhal

axhal-->axnet
axsync-->axnet
axtask-->axnet
axdriver-->axnet

axalloc-->axruntime
axconfig-->axruntime
axdriver-->axruntime
axhal-->axruntime
axlog-->axruntime
axnet-->axruntime
axdisplay-->axruntime
axtask-->axruntime
axprocess-->axruntime
axtask-->axsync
axtask-->axprocess
axfs-->axprocess
axhal-->axprocess

axalloc-->axtask
axhal-->axtask
axconfig-->axtask
axlog-->axtask

Loading

即axprocess模块依赖于axtask等模块，在此基础上你将axfs添加到axprocess中就可以完成进程中文件描述符的支持。

[Azure-stars]

顺带一提，我也把axsyscall从原先的task模块中解耦出来了，现在axsyscall也是依赖于axprocess进行的。

graph TD;
axsync-->axdisplay
axdriver-->axdisplay

axhal-->axdriver
axalloc-->axdriver
axconfig-->axdriver

axdriver-->axfs
axsync-->axfs
axtask-.dev.->axfs

axconfig-->axhal
axalloc-->axhal
axlog-->axhal

axhal-->axnet
axsync-->axnet
axtask-->axnet
axdriver-->axnet

axalloc-->axruntime
axconfig-->axruntime
axdriver-->axruntime
axhal-->axruntime
axlog-->axruntime
axnet-->axruntime
axdisplay-->axruntime
axtask-->axruntime
axprocess-->axruntime
axtask-->axsync
axtask-->axprocess
axfs-->axprocess
axhal-->axprocess

axtask-->axsyscall
axprocess-->axsyscall
axsyscall-->axruntime
axalloc-->axtask
axhal-->axtask
axconfig-->axtask
axlog-->axtask

Loading

上述依赖关系图没有画出全部的依赖链，否则会过于复杂，仅画出了其中几个关键节点。详细的依赖关系见代码。

[Azure-stars]

关于你提到的线程控制块中有指向进程的弱指针，这里我做了一层抽象。我在线程控制块中仅保留了所属进程的ID，而没有保留指针。在进行线程回收时，我发现当前线程回收的调用接口仅有syscall_exit接口，所以我将syscall_exit先交给进程控制块执行。进程控制块调用线程回收函数结束之后，判断当前回收的任务是否是对应进程的主线程。若是，则在进程控制块内进行资源回收。

相比于之前的逻辑，回收操作放在了进程控制块而非线程控制块，从而完成解耦。

对于不需要进程支持的系统，仅需要将线程对应属性置为0即可。

[Azure-stars]

@chunchunyd

[Azure-stars]

关于支持进程情况下的任务启动参考（以下仅以单核情况出发，多核情况暂未考虑）
依据原先arceos提供的调度任务序列等模块，在初始化调度序列RUN_QUEUE时将gc_task（任务回收模块）设定为当前核上的任务。对于内核即将运行的初始化用户程序，则加入到调度序列中等待被调用。上述过程基本与arceos一致。
之后由于需要启动gc_task不断检查当前是否有新任务完成运行等待回收，因此需要手动调用任务上下文切换context_switch函数，运行gc_task的任务上下文，再通过gc_task来唤醒所有等待中的进程运行并将其回收。
手动调用的思路与rCore类似，即设置一个空的任务上下文存储当前的ra等寄存器，然后将gc_task的上下文存入寄存器中。
对应代码如下：

/// 开始进行调度，我们先执行gc任务，通过gc任务逐个执行并收集RUN_QUEUE中的任务
/// 所以先切换到gc对应的任务上下文即可
pub fn start_schedule() {
    // 若是第一次执行任务，curr应当为gc
    let curr: CurrentTask = current();
    #[cfg(feature = "preempt")]
    curr.set_preempt_pending(false);
    curr.set_state_running();
    unsafe {
        let prev_ctx_ptr = TaskContext::new_empty();
        let next_ctx_ptr = curr.ctx_mut_ptr();
        // The strong reference count of `prev_task` will be decremented by 1,
        // but won't be dropped until `gc_entry()` is called.
        (*prev_ctx_ptr).switch_to(&*next_ctx_ptr);
    }
}

之后在rust_main中调用该函数即可开始运行。

[chyyuu]

做的不错！是否有个README.md，让其他同学知道如何运行进程模式的应用程序？ @Azure-stars

[Azure-stars]

进程支持下的应用程序启动

1. 应用程序文件准备：

   若仅有应用程序源码，则需要将准备运行的应用程序与用户库进行联合编译，生成可执行文件。编译方式可以参考rCore（[rcore-os/rCore: Rust version of THU uCore OS. Linux compatible. (github.com)](https://github.com/rcore-os/rCore)）的`user`库编译方式。

   比赛中测例通过联合编译之后也会生成可执行文件。

   生成流程如下：

   1. 在rCore的user库下bin文件夹新建一个名为helloworld.rs的文件
   2. 在该文件中编写您想运行的应用程序源码。
   3. 在user路径下执行make build指令。
   4. user/target/riscv64-unknown-none-elf/release/helloworld即为所生成的可执行文件。

   由于当前未引入文件系统支持，因此采用固定路径链接可执行文件。请将预备执行的可执行文件拷贝在arceos的apps/helloworld路径下，由于后续不打算在固定路径链接上做拓展，因此写死初始化运行程序的文件名必须为helloworld。

   若需要引入多个文件，在将多个文件放入到对应目录下后，还需要修改axruntime/src/link_app.S与源码中某些部分。由于不打算后续扩展，因此当前写死仅支持两个文件同时链接加载。初始化应用为helloworld，另一个应用为second。

2. 启动应用程序运行指令：

   在根目录下运行

   make A=apps/helloworld ARCH=riscv64 LOG=info SMP=1 run

   即可启动任务调度器，反复检查当前是否有可执行的任务。在执行完所有任务之后，任务调度器不会退出，而是继续循环，类似于shell的执行逻辑。

3. 若想运行其他内容的应用程序，请在原先helloworld的源码上进行修改，引入其他系统调用之后再次编译生成可执行文件并且拷贝到对应目录。

4. 当前由于未支持文件系统，上述操作略显冗余。之后会引入文件系统支持，使得流程更为简便。

[Azure-stars]

上述内容同步更新到本人的arceos仓库的README.md

[Azure-stars]

fix：为了更加简便的进行编译，建议使用https://github.com/rcore-os/rCore-Tutorial-v3仓库中的代码进行联合编译。

[Azure-stars]

更新当前依赖关系图：将mem虚存与process分离开，process作为一个容器存储task，mem，fs等资源，同时将文件系统接入arceos中。

graph TD;
axsync-->axdisplay
axdriver-->axdisplay

axhal-->axdriver
axalloc-->axdriver
axconfig-->axdriver

axdriver-->axfs
axsync-->axfs
axtask-.dev.->axfs

axtask-->axfs_os
axfs-->axfs_os

axconfig-->axhal
axalloc-->axhal
axlog-->axhal

axhal-->axnet
axsync-->axnet
axtask-->axnet
axdriver-->axnet

axalloc-->axruntime
axconfig-->axruntime
axdriver-->axruntime
axhal-->axruntime
axlog-->axruntime
axnet-->axruntime
axdisplay-->axruntime
axtask-->axruntime
axprocess-->axruntime
axtask-->axsync
axtask-->axprocess
axfs_os-->axprocess
axhal-->axprocess

axprocess-->axsyscall
axsyscall-->axruntime
axalloc-->axtask
axhal-->axtask
axconfig-->axtask
axlog-->axtask

axhal-->axmem
axalloc-->axmem

axmem-->axprocess

Loading

说明：axfs是对fat32文件系统的交互模块，而axfs-os是将axfs移植进内核的中转模块。在axfs-os中实现了包括文件描述符等一系列适用于内核文件操作的数据结构。

[shzhxh]

需求描述

arceos现在是unikernel模式，要给arceos增加宏内核模式，且支持aero操作系统的用户态程序(包括图形界面程序)。

目标

• 对三种架构(x86_64, arm64, riscv64)都要进行适配，而不应在某个架构上跑不起来。
• 支持的是宏内核模式，而不应限制为只能实现某个宏内核。
• 是源码级支持aero操作系统的用户态程序，而不是二进制级。

规划

1. 理解arceos的实现。分析宏内核的本质。思考arceos怎么加入宏内核模式。计划15天。
2. 依据上步思考的结果，实现宏内核模式。计划30天。
3. 适配aero操作系统的用户态程序。计划45天。

[shzhxh]

进度报告：分析arceos实现。

1. 编译与链接分析
2. 执行过程分析
3. 各模块分析

[chyyuu]

@xushanpu123 5月31日前的问题：syzkaller 用到了哪些Linux syscall？ 请给出分析回答。

[shzhxh]

进度报告：arceos与宏内核对比。

1. 计划将新内核命名为清河(qinghe)，创建了一个组织qinghe-os存放与清河相关的代码。
2. 准备将所有的文档都放在一个wiki里：qinghe/wiki
   • 添加新文档：arceos与xv6对比
   • 添加新文档：arceos与aero对比
   • 更新了文档规划：添加了设计原则，细化了宏内核的实现步骤

[shzhxh]

进度报告：实现一个最小系统。

1. 文档先记录在此issue上：一个可在qemu上运行的最小二进制镜像 qinghe-os/qinghe#1
2. 正在添加aarch64架构的支持，代码：https://github.com/qinghe-os/qinghe/tree/dev

[shzhxh]

进度报告：最小系统实现总结，准备开始实现进程管理。

1. 最小系统的实现，增加了进度记录：一个可在qemu上运行的最小二进制镜像 qinghe-os/qinghe#1
2. 进程管理的实现，准备记录在此issue上：进程管理系统的支持 qinghe-os/qinghe#7
3. 更新了文档规划：
   • 添加目标：用stable版rustc编译
   • 添加设计原则：简单直接

[shzhxh]

进度报告：开始实现进程管理。

• 学习rCore里的进程实现。

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[mingzi47]

在starry-next中支持vdso功能

第一周（7.13-7.19）

目前主要在 x86 和 riscv 上进行工作。

完成的目标：

• 将 Linux 中的 vdso.so 嵌入到 starry-next 中

• 实现 应用程序 通过 libc 调用 vdso 中的代码

TODO

• 实现 vdso data 更新的逻辑

• 支持更多架构

• 优化代码

日报仓库

daily-record