首页 【开发日志】rCore-N (共享调度器 fork) 搭建和踩坑
文章
取消

【开发日志】rCore-N (共享调度器 fork) 搭建和踩坑

注意,这是运行 https://github.com/CtrlZ233/rCore-N (开源操作系统训练营项目 6,共享调度器 rCore-N)的教程,而不是 rv-n-ext-impl 内的 rCore-N https://github.com/duskmoon314/rCore-N 的教程。

关于这两者,共有的教程在 rv-n-ext-impl 文档:使用教程 一章。 这里的一些流程与那一章重合,但我这里会把流程补充完整并梳理清楚。

流程介绍

  1. risc-v 的用户态中断拓展草案非废除,相应的一些工具尚不支持或者该功能被移除(缺乏用户态中断相关的寄存器、指令、LPIC)
    • qemu 未实现用户态中断,所以需要一个添加了该功能的 fork (基于 qemu5)
    • LLVM IR 移除了用户态中断实现,而 Rust 的 asm! 其实是对 LLVM IR 的内联汇编语法的简单包装,所以需要固定 Rust 工具链到历史版本号
  2. 由于原 rCore-N 声明只维护 justfile 脚本,所以使用 just run 而不是 make run 来运行 os
    • 注意:需要修改 SERIAL_FLAGS 中的三个 pts 设备号,它们应指向当前运行的虚拟终端设备号
    • justfile 是 just 程序识别的脚本文件,你需要安装 just 程序

1. 安装具有用户态中断的 qemu

1
2
3
4
5
6
7
8
9
# 创建一个文件夹 async-os
mkdir async-os
cd async-os

git clone https://github.com/duskmoon314/qemu.git --depth 1
mkdir qemu-build
cd qemu-build
../qemu/configure --target-list="riscv64-softmmu" --extra-cflags=-Wno-error
make -j

注意这里添加的 --extra-cflags=-Wno-error 传递给 gcc 的编译器参数,如果没有它,编译 qemu 出现警告会无法继续下去。

2. 下载 rCore-N 代码并指定 Rust 工具链

1
2
3
4
5
6
7
# 在 async-os 下,如果你从上一步来,那么先 cd ..
# 当前测试的提交号为 41796b8

git clone https://github.com/CtrlZ233/rCore-N.git --depth 1
cd rCore-N
# 创建并编辑 rust-toolchain.toml 文件
vim rust-toolchain.toml
1
2
3
4
5
6
# rust-toolchain.toml 内添加以下内容
[toolchain]
profile = "minimal"
channel = "nightly-2023-01-03"
components = ["rust-src", "llvm-tools-preview", "rustfmt", "clippy"]
targets = ["riscv64gc-unknown-none-elf"]

这个工具链文件是由 rustup 识别的,它表示使用文件内的工具链,而不是本地工具链。

对这个文件内容一些解释

  • minimal profile 包含 rustc, rust-std 和 cargo
  • channel 固定到 2023 年 1 月 3 日的 nightly Rust (代码中使用了 nightly only features)
  • components 表示添加一些额外的组件,有了这些组件,你就可以在这个项目中正常使用它们
    • 如果你需要固定 RA 版本的话,还可以在这个列表中添加 rust-analyzer —— 需不需要由你的 IDE 配置决定
  • targets 表示添加额外针对一些目标平台的 交叉编译工具链

这个工具链设置应用于 os、lib_so、user 这些子目录中的 Rust 项目。

3. 运行 rCore-N (基于 tmux)

当前在 async-os/rCore-N 文件夹下。

在 tmux 中,使用 Ctrl-b 快捷键触发 tmux 相关的功能,比如 Ctrl-b + % 向右分割一个新终端 pane,Ctrl-b + " 在这个右终端 pane 中向下分割一个终端 pane,此时你可以直接控制三个终端。使用 Ctrl-b + 方向键 聚焦于一个终端。

关于 tmux 的简单使用介绍,见我的 博客

在右侧的两个终端中,它们的当前目录继承了父进程,即 async-os/rCore-N,聚焦它们,并运行 sleep.sh 脚本(比如 ./sleep.sh), 它会将终端清除,并打印当前 pts 设备文件路径。这两个终端作为内核的输出和用户态输出(和输入)。

假设这两个 pts 路径为 /dev/pts/2 (上)和 /dev/pts/3 (下)。

聚焦于左侧终端,使用 vim justfile,修改 SERIAL_FLAGS 中的相应值: SERIAL_FLAGS := "-serial /dev/pts/2 -serial /dev/pts/3 -serial /dev/pts/3 。注意后两个串口是一样的 pts。

顺便说一句,justfile 中,第一行的 QEMU 变量指定了第一步的 qemu 路径,如果你按照我的项目文件结构,不需要改动,否则需要改成相应的路径。

一切就绪,使用 just run 或者 LOG=INFO just run 编译用户程序和操作系统,初次运行会需要一些时间,比如

  • 本地没有安装 rust-toolchain.toml 指定的工具链,则自动安装
  • 拉取 crates.io 完整的 registry:由于工具链太旧,不支持 sparse 方式下载 package,所以下载需要一些时间;如果网不好,可以自己去换源

然后在右下角的终端,可以输入用户程序名称来运行程序。这些程序名来自 ../user/src/bin/。如果你使用 LOG=INFO just run,右上角会显示这些程序名。

如果要退出 rCore-N,在 qemu 界面(左侧终端),按 q 和回车(或者直接 Ctrl-d)。

3. 运行 rCore-N (基于 vscode)

我不使用 vscode,这里只放一些成功运行起来的图片,除了终端控制的方式不一样,其余细节是一样的,关键就两点:

  • 终端 pts 每次可能不一样,所以需要修改 justfile 的 SERIAL_FLAGS
  • just run 运行起来

其他一些记录

qemu 的 CPU 占用接近 100%

目前代码似乎以 spin + 轮询的方式进行任务调度,所以 qemu 将每个核的 CPU 占用到 100% 是正常的。也就是说,多核情况下 rCore-N 会导致 400% CPU 使用。

即使在阶段 2 的练习中,rCore 系统运行起来后,qemu 的 CPU 占用也是 100%。

以上数据仅供参考。

核数小于 4 的机器暂时不能正常运行 rCore-N

这个问题是促使我写这个文章的最大原因,排查了一整天。

我的服务器核数比较小,所以直接运行 just run 并不能显示出 user shell 界面,更别说运行了。

调整内核代码中的 CPU_NUM={1,2,3} 可以调出 user shell 并运行命令; 但不意味着正常系统运行,机器的核数不够至少会造成如下影响(我无法解释,这只是我的一些观察):

  • shell 运行一次某些程序之后,终端也没反应了(不再显示 »、输入无反应)

最终,我只能在自己的 Windows11 WSL 环境下重新搭建了所有必要的开发环境,在默认的 CPU_NUM=4 的情况下,终于正常运行起来了(本地机器 CPU 数量大于 4)。

本文由作者按照 CC BY 4.0 进行授权

【笔记】rCore (RISC-V):虚拟内存

【开发日志】embassy 使用记录