实验小项目招新：基于arceos框架直接支持Linux App的宏内核

[chyyuu]

网址：

• https://github.com/Azure-stars/arceos
• https://github.com/c0per/arceos
• https://github.com/chunchunyd/arceos
  开发日志：
• https://github.com/Azure-stars/arceos/tree/doc/doc
• https://github.com/c0per/oscomp-weekly
• https://github.com/chunchunyd/OSComp/Reports

参考：

• 2021/2022年OS内核赛道的比赛作品 : os.educg.net
• https://github.com/nuta/kerla
• https://github.com/Andy-Python-Programmer/aero
• 与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]

[shilei-massclouds]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]

[OSLearning365]