实验小项目招新：arceos支持tokio

[chyyuu]

目标：
探索tokio runtime运行在arceos上，分析其中的I/O性能提升的可能性。涉及 rust std, async, io support等。

初步计划：

1. 分析基本的rust std库对OS的依赖，主要参考rusty-hermit如何支持rust std的做法；
2. 尝试让helloworld based on rust std库能运行在arceos上；
3. 分析tokio需要的基本操作系统功能，对接arceos；
4. 用基于tokio的app（如http-server）进行初步的集成测试。

参考：

• https://tokio.rs/
• https://github.com/rcore-os/arceos
• rusty-hermit

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

[shilei-massclouds]

Rusty-hermit学习过程

学习rusty-hermit，尝试为arceos支持tokio准备一些参考信息。

Rusty-hermit构造Unikernel Image过程跟踪

1. 以hello-world为目标，跟踪hermit构建Unikernel Image的过程。

   #[cfg(target_os = "hermit")]	/* 指定目标OS是hermit */
   use hermit_sys as _;	/* 引入构造image的工具 */
   
   fn main() {
       println!("Hello, world!");
   }

   前两行要求引入hermit_sys，它其实是构造image的工具。对应Cargo.toml中，

   [target.'cfg(target_os = "hermit")'.dependencies]
   hermit-sys = { path= "../hermit-sys" }

   拷贝hermit_sys的源码目录，与hello-world平级，便于调试。

2. 查看hermit_sys，发现关键起作用的是它的build.rs。

   hermit借助rust的build脚本预执行的机制，即build.rs的main函数，来定制对应用hello-world的编译和构造过程。

   main函数

   let targets_hermit =
       matches!(env::var_os("CARGO_CFG_TARGET_OS"), Some(os) if os == OsStr::new("hermit"));
   if !targets_hermit || runs_clippy || is_docs_rs {
       return;
   }

   只有明确指定目标OS是hermit时，后面的构建过程才会执行。（hello-world主文件第一行的作用）

   let kernel_src = KernelSrc::local().unwrap_or_else(KernelSrc::download);
   kernel_src.build();

   下载hermit OS核心crate源码，即libhermit-rs，然后编译构建。

3. 下载过程就是如果libhermit-rs目录不存在，就下载tar格式libhermit-rs源码包，然后解包。

   为跟踪调试，修改源码包解开的位置，放在hello-world的平级目录。下步就可以在该目录下进行代码跟踪。

4. 重点是build过程

   具体过程在KernelSrc的build()函数中实现，大致分为三步：

   4.1 为cargo命令准备参数

   重点是下面这段

           // Remove rust-toolchain-specific environment variables from kernel cargo
           cmd.env_remove("LD_LIBRARY_PATH");
           env::vars()
               .filter(|(key, _value)| key.starts_with("CARGO") || key.starts_with("RUST"))
               .for_each(|(key, _value)| {
                   cmd.env_remove(&key);
               });

   当前实际正在执行cargo编译，下面需要嵌套执行cargo去编译libhermit-rs。嵌套过程中，需要避免本级的环境变量影响嵌套级的环境变量，所以用env_remove过滤掉那些可能造成干扰的环境变量。

   4.2 执行cargo命令编译libhermit-rs，即hermit OS核心

   4.3 从嵌套编译libhermit-rs的命令过程中返回，此时已经得到了libhermit-rs.a静态库，后面就要把hello-world和静态库联编到一起形成image。注意：此时又回到了顶级cargo的执行环境中。

   需要告知cargo在后面的执行过程中，如何找到libhermit-rs.a静态库，并且建立最终image与libhermit-rs源码之间的依赖关系，当源码变动时，自动去重新构建image。

   用println!输出的方式为后面rustc执行指定参数

   有三个关键参数

   /* 告知libhermit-rs.a静态库搜索路径 */
   println!("cargo:rustc-link-search=native={}", lib_location.display());
   /* 告知是静态库！！！ */
   println!("cargo:rustc-link-lib=static=hermit");
   /* 建立最终image与libhermit-rs源码之间的依赖关系 */
   println!("cargo:rerun-if-changed={}", self.src_dir.display());

正在跟踪libhermit-rs的构建过程和内部实现。待续...

[shilei-massclouds]

RustyHermit的构成

RustyHermit是一个Unikernel OS的构造工具，最终会生成一个裸机（或虚拟机）上运行的Unikernel Image文件。

• Hermit-Sys是构造工具，它是最先被构造和执行的。它通过执行一系列步骤，完成了HermitOS(libhermit.a静态库形式)的构建。传统上通常写Shell script做此类工作，但是这里是基于Rust的自身机制。
• 最终输出是一个单应用的Unikernel Image，包括四个部分：
  • 应用和它依赖的其它应用库
  • Rust-std库：由于target是x86_64-unknown-hermit，std库被条件编译，后端调用hermit-ABI的接口来支撑实现。
  • hermit-ABI接口：它仅仅是函数声明，用作Rust-std库与HermitOS的接口协议。所以最终std库与HermitOS是之间连接在一起的，中间没有其它运行时的层次。例如rust-std库需要read，就会调用hermit_abi::sys_read(UNDEF符号)，而HermitOS(即libhermit.a)提供hermit_abi::sys_read的实现，二者之间链接resolve符号，没有中间层。
  • HermitOS：典型libos的实现，静态库形式，libhermit.a由Hermit-Sys工具首先构建出来。它是由两个静态库打包而成。
    • libhermit.a(同名)：其中主要包含的是hermit-abi的实现，例如sys_read等等。它基于x86_64-unknown-none编译。
    • hermit-builtin.a：包含两类，一是内存基本操作相关memcpy/memset/...等；二是少量的系统符号，例如_start。它基于x86_64-unknown-hermit编译。

构造顺序

1. 构建Hermit-Sys工具，基于host target，即x86_64-unknown-linux-gnu
2. 下载libhermit-rs源码，里面包含子目录hermit-builtin。
3. 编译libhermit-rs成为静态库libhermit.a
4. 编译hermit-builtin成静态库hermit-builtin.a
5. 用llvm工具ar，把上面两个静态库打包成最终的libhermit.a，即HermitOS
6. 以target=x86_64-unknown-hermit编译std库，后端依赖hermit-abi
7. 由于std接口没有改变，所以应用如传统方式一样的编译。

关于Target(x86_64_unknown-hermit）& rustc & llvm & std

• rustc源码中包含对x86_64_unknown-hermit的处理，主要是解析成编译参数，指导自身和llvm去编译std库等。
• llvm源码中也包含对x86_64_unknown-hermit的处理，但是改动更少，看效果就是给最终的ELF文件头加上OS/ABI值-standalone。
• rust-std库包含有针对hermit的代码分支：所以x86_64_unknown-hermit影响最大的就是rust-std库的编译。通过指定target，生成的std库的后端就会依赖于hermit-abi接口。

小结

1. Rusty-hermit的情况与之前预计类似，只是应该不用编译rustc，只是需要重新编译std库。
2. 虽然rustc和llvm中都有针对hermit的处理代码，但是改动很少。目前看这个target与x86_unknown-none应该非常类似。我觉得可以在下步工作去验证一下，就是hermit不用在rustc和llvm中提交专门处理的代码，也能实现当前功能。

进一步工作的想法

1. 如小结第2点，不用x86_64_unknown-hermit，自定义一个target.json(基于x86_64_unknown-none)看看是否能够构建出二进制相同的hermit image。(llvm中针对hermit，会设置elf头中的OS/ABI，我们可以试试elfedit直接改)。
2. 继续实验其它的hermit demo。
3. 试试能否在hermit上编译运行tokio。

[shilei-massclouds]

实验目的

1. 验证只需要修改rust-std，不必修改rustc和llvm，就可以达到rusty-hermit目前的能力和效果。
2. 通过实验深入学习rusty-hermit的流程和细节，为下一步arceos相关工作做准备。

实验思路

1. 自定义一种新的target，名为monk，基于这种target去编译构造Rusty-Hermit。
2. 保持rustc和llvm不变。那么rustc和llvm中就不包含处理这种新target代码。
3. 需要修改rust-std库，增加针对monk target条件编译的代码。另外，如Hermit-sys，libhermit-rs/xtask等也需要做类似的修改来支持新的target。通过这个过程，加深对hermit的理解。

实验步骤

步骤1：导出x86_64-unknown-hermit，定义新的自定义target：x86_64-unknown-monk

1. 导出x86_64-unknown-hermit，作为自定义target的基础，新target名为x86_64-unknown-monk

   rustc +nightly -Z unstable-options --print target-spec-json --target x86_64-unknown-hermit > x86_64-unknown-monk.json

2. 修改x86_64-unknown-monk.json

   "is-builtin": false,					// 之前是true
   "llvm-target": "x86_64-unknown-hermit",	// 暂时不改
   "os": "hermit",							// 暂时不改

3. 改rust-std标准库的build脚本(std/build.rs)

       let target = env::var("TARGET").expect("TARGET was not set");
       if target.contains("freebsd") {
   		... ...
       } else if target.contains("linux")
   		|| ... ...
           || target.contains("hermit")
           || target.contains("monk")			/* !!! 加上这行 !!! */
   		|| ... ...
           || target.contains("nto")
       {
           // These platforms don't have any special requirements.
       } else {
           println!("cargo:rustc-cfg=feature=\"restricted-std\"");
       }

   环境变量TARGET就是“x86_64-unknown-monk”，现在我们加在hermit的下一行中。如果不加，feature会被指定"restricted-std"，最后就会编译一个受限的std库，那应该不是我们期望的。

4. 编译和测试成功，只是生成的image文件到了target/x86_64-unknown-monk的目录下。

步骤2：修改rust-std库和hermit的相关库

1. 修改x86_64-unknown-monk.json

   "is-builtin": false,					// 之前是true
   "llvm-target": "x86_64-unknown-none",	// 官方内置的NONE target，不使用hermit定制的llvm-target
   "os": "monk",							// 对应于新的target_os

2. 修改rust-std库，和hermit-sys以及libhermit-rs的代码。仿照hermit的条件编译，增加monk。
   具体修改见实验项目的源码[email protected]:shilei-massclouds/step-hermit.git，具体步骤

git clone [email protected]:shilei-massclouds/step-hermit.git
cd ~/.rustup/toolchains/nightly-2023-03-15-x86_64-unknown-linux-gnu/lib/rustlib/src
mv rust bak_rust
ln -s /home/cloud/gitRust/step-hermit/rust ./rust
cd helloworld
./build.sh
cd rusty-loader
./build.sh
cd ..
./start.sh

注意：建立符号链接时那个/home/cloud/gitRust/是我的工作目录，即step-hermit的所在目录，请对应修改。

3. 显式信息“Hello, monk!"，表示成功。

[shilei-massclouds]

目标

把tokio移植到rusty-hermit，为下一步tokio结合arceos做准备。

准备工作

1. 编写一个最简单的tokio应用tokio_hello，放到rusty-hermit/examples目录下编译，看看报什么错？！

2. 编译结果：socket2和mio这两个crate有许多unresolve的符号。它们都是tokio依赖的crate。

3. 把tokio、socket2和mio克隆到rusty-hermit目录下，加入到git管理，在当前项目下编译调试。

4. 分析编译报错的原因：socket2和mio只是实现了unix和windows两种target_family，而hermit不属于任何一种，因而缺少针对它的sys模块。

思路

在linux下原本层次如下：

graph TD;
tokio --> mio
tokio --> socket2
mio --> libc_syscall
socket2 --> libc_syscall
libc_syscall --> linux_kernel

Loading

我们准备改造的hermit目标层次结构：

graph TD;
tokio --> mio
tokio --> socket2
mio --> hermit_abi
socket2 --> hermit_abi
hermit_abi --> libhermit

Loading

因此，思路总结如下：

1. mio和socket2的上层接口不变；增加面向hermit的后端sys模块，与现有的sys for unix/windows并列。
2. hermit后端sys模块调用hermit_abi实现本身功能。
3. 所以，当前重点，对照mio/socket2的调用需求和libhermit提供功能的匹配程度。

过程

1. 对照mio/socket2的调用需求和libhermit提供功能的匹配程度

   今天先分析mio/socket2的功能。socket2就是对socket的基本封装；mio是非阻塞的网络操作，以Poll为基本方式。

   对照来看，libhermit的net模块大致能够覆盖最基本的网络操作要求；但是对于poll之类的和event之类的高级的调用和参数，存在明显的差异，这部分可能多消耗一些工作量。

2. 为mio/socket2增加空的sys for hermit实现，编译报错缺什么，就增加什么。主要参考是现有的sys for unix实现。进行中

3. 未完待续...

[shilei-massclouds]

在rusty-hermit上支持tokio的实验情况。

1. tokio需要socket2和mio的支持，其中socket2封装基本的socket操作，而mio背后是epoll。
2. 相对socket2和mio来说，hermit是未实现的target，所以编译报错。
3. socket2支持hermit相对容易，多数socket操作都可以对应上hermit_abi。工作量应该不大。
4. mio支持hermit比较麻烦，目前rusty_hermit连传统的poll也未能实现(abi有poll，但是link_name就错了，显然未实现)。所以需要补充对epoll的支持。思路是参照linux的epoll实现补上。

[shilei-massclouds]

基本思路

HermitOS即libhermit.a由三部分构成：

1. Hermit-builtin：源码在独立的目录，其中包含panic和一系列数学函数，暂且不管。
2. 相当于Crt*的初始部分：Hermit是小众，所以rustc中仅包含一点验证性的代码，不会替它产生这部分代码。所以Hermit是自己在libhermit.a实现了这部分，最后被联合编译到最终的执行程序中。但是，这块代码与其他部分有一定的耦合性。
3. hermit功能模块：主体部分，hermit-abi的后端。这是我们主要需要替换的目标。这部分被剔除后，剩下的基本就是上述第2部分。

总体步骤

1. 用ArceOS的功能逐步替换hermit的对应功能，详细步骤见下节。
2. 先保留hermit-abi中的各个"syscall"定义，只是更名为arceos-abi，下步再根据需要调整。
3. 用axhal for x86_64的引导部分，替换目前的rusty-loader。
4. 用一系列makefile调用脚本，取代hermit-sys的功能。

针对hermit功能模块的替换步骤

对于ArceOS Apps中的每个应用：

1. 去除no_std/no_main后，在Hermit运行成功；
2. 确定本应用涉及的arceos-abi(原来是hermit-abi)的"syscall"。注："syscall"实际只是C 函数符号声明。
3. 用ArceOS后端替换Hermit后端，支持上面涉及的"syscall"。
4. 重新编译测试成功。

当前进展

1. HelloWorld应用
   • 主要过程：println宏 -> sys_write(stdout) -> console.output。涉及两部分：console和文件描述符管理。
   • 暂时延用hermit中的fd文件描述符管理。其中，标准输入/标准输出/标准错误两个描述都指向console
   • 用axhal的console替换hermit的console。目前axhal的x86_64平台还不支持，暂时用uart16550的crate实现代替输出，目前看显式正常。
   • 测试通过。
2. Memtest应用
   • 主要涉及sys_malloc/sys_realloc/sys_free
   • 直接用axalloc中的globalallocator替换hermit的对应实现即可，但是同上，需要等待x86_64平台的引导过程中初始化内存代码实现。
   • ... ...

小结

目前看，Hermit大部分功能在ArceOS中都能找到对应；而文件管理之类的功能，我们可以暂时延用hermit的，最后进行review和修改。所以，工作难度不大，但是应该有一定工作量。如果有同学参与进来，可以参考本文档并在GitHub协作，如下链接

[email protected]:shilei-massclouds/std-arceos.git

[chyyuu]

关于学习和借鉴rustyhermit的有趣讨论（jyk，sl）：

背景：rustyhermit（一种rust-based unikernel）有对rust std的直接部分支持，本小组成员在如何借鉴rustyhermit，在arceos中支持部分rust std，以进一步支持tokio

jyk: 建议一开始做时就不要和hermit有任何关系，它的hermit-abi，libhermit，rusty-loader在我们这里都是没有对应关系的，直接调用libax一个就够了

sl: 我感觉目前这条路(基于libhermit，逐步替换位libarceos)是比较稳妥的 可以最大限度复用hermit成果 逐步替换就能达到目标 hermit趟过的路我们没有必要再趟一遍 libax不足以支撑std。其实，libhermit是由三部分构成的，其主体部分基本对应arceos除apps之外的全部。另两部分我们是没有的。rusty-loader 就基本对应于axhal中boot部分，调通再简化合并也比较方便。

jyk: 有必要再趟一遍，他的不够简洁

sl: 先把路走通 再简洁

jyk: 肯定走得通

sl: 不争了 你讲的说服不了我 我先按我目前的想法走下去

jyk: libax中已经实现了Stdin和Stdout，为何还要通过sys_write再包一层？文件已经实现了File结构，为何还要用fd再实现？

sl:

1. 通过sys_write 去写stdout正体现了unix一切皆文件的设计思想 我认为是很好的抽象 没有什么不简洁的 反而正是有这样一类抽象层存在 简化了unix设计 而且这个包装我不认为存在多少性能消耗
2. 如果说arceos 实现了file结构 与hermit目前的fd功能重合 那对应替掉就好了 不是什么大问题
3. 我认为hermit_abi是一个很清晰的分界 它把整个系统清晰的分成了两个部分。而且它是extern "c"声明，各种语言互调用的基准。在它之上是rust 的std库，将来还可以支持各种语言的bindings。例如，咱们那个与libax并列的c_libax就很奇怪，如果有abi这层，c_libax就可以放在上面，我认为实现会简化。abi下面 把arceos功能 完全封装进去。上层下层仅能通过abi交互，应该是一个好的松耦合设计。
4. 我认为hermit各部分与arceos的対应关系是基本清楚的 包括内部功能都差不多能找到对应 是可以实现对应替换的。只是hermit多了一些东西，而多的这些基本是我们可以用的。

jyk: 是计划有一个abi层，会统一处理syscall/fncall，linux abi/arceos abi，但这是在libax之下的，libax对应std后端，std应该直接调用libax而不是abi。目前已实现的是一个假设的arceos abi，专门为rust应用调用rust内核而设计，还在探索，特地不用fd等传统abi。sys_write之后也会实现，但那只是为了兼容linux应用

sl: 我认为libax对应于hermit直接在abi下面那一部分代码 就是你前面说的实现sys_write那一层的东西 它应该在abi下面

jyk: 不是，它就是一个简化的std。abi那一层需要有，但目前还没有特别区分

sl: 专门为rust应用内核设计是什么目的 性能更好吗 我不认为基于abi就能差到哪里去 是有实验数据支撑吗? 手指头快断了

jyk: 比如闭包，async/await函数

sl: 我认为libax不适合定位为std 那rust现在官方的std咋办 你用libax替掉它？

jyk: 作为后端

sl: 如果作为std后端那我就觉得 std直接调用rust和通过abi这层再调用rust没有什么性能差别 特别这里还不涉及你提到的闭包等高级rust特性 原来std后端几乎都是C实现的os 基本都提供C接口。

除非你想重构大调整std

hermit存在应该有段时间了 之前是c实现 后来才搞得rust 他们应该面临过咱们正在或者即将面临的问题 咱们可以通过这个逐步对应替换的办法 深入的学习一下他们的东西 哪怕它不好 也确切知道它哪里不好。我有个感觉：各位老师同学别见怪。咱们可能对其他os的学习，尤其是总结方面可能是不够的。往往想做一个东西的时候去参考一下，得到想要的就放一边了。很少会专门对一个os进行完整的系统的分析。这样可能会错过一些像架构设计方面只有从整体去看才能得到的好东西。当然也许只是我了解的情况太少。说的不对的请见谅。

jyk: 没说大改std啊，目前libax就是面向std来的，api都很像，接过去很容易

sl: 那std调用abi。 libax在下面实现abi也没什么难的吧

jyk: 我认为hermit已经没什么好学的了，它实现的我们都能实现，只有遇到问题解决不了才去参考它一下，现在就是要做和它不一样的东西。不如去学redox，theuses。hermit一眼就看出它的思想了，我们都能想到

sl: 好吧 之前问题绕远了 其实这个才是根本问题。你认为他没什么好学的。我认为需要好好学。我们解决不了问题的时候去参考人家。正说明人家有好东西。只是有些东西现在发现了。有些东西要等我们遇到问题时才能发现。