@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

我现在已经完成了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

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

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

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

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

关于支持进程情况下的任务启动参考（以下仅以单核情况出发，多核情况暂未考虑）
依据原先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中调用该函数即可开始运行。

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

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. 当前由于未支持文件系统，上述操作略显冗余。之后会引入文件系统支持，使得流程更为简便。