Derui Yang

thx

> 如果没有boot option，做CI测试时应该采取什么样的策略来获取os的执行状态呢，就像这个issue中提到的是否能保持os的在线 [#286 (comment)](https://github.com/rcore-os/zCore/issues/286#issuecomment-1120419151) 我的设想是通过 qemu 外设来传递信息。一种可能的方案是内核中增加一个进程通过 qemu 外设向外发送心跳和测例运行状态，外部测试框架监控这些信息，察觉测例失败、超时、内核崩溃等事件，通过开关 qemu 控制测例运行。

最新思路，使用 Qemu 的 test 虚拟外设把 Qemu 里的错误码传出来，CY 老师在 rCore 上已经实现。

目前内核的测试在 Qemu 上和真机上是不一致的。 在 Qemu 上采取了简单的方式：为每个测例都开启一个独立的 Qemu 实例，运行完后无论成功失败，立即关机。这个做法在真机上是不可行的，因为真机启动不好控制，重启还可能需要掉电，无法自动进行。所以真机上必须每次启动都执行尽量多的测例，当且仅当无法继续测试时才关机。无法继续测试的情况包括没有更多测例或内核已经崩溃。实际上，既然这是唯一可行的方案，就一定会被采用，OS 比赛内核赛道的测试就是这样执行的，所有参赛的内核也都支持这样运行测例。 实际上，现在的 qemu 测试还有另一个问题：只能测试功能，无法测试稳定性问题，比如内存泄漏，因为每个测例完成后都会重启清除状态。如果一次运行多个测例甚至支持[这个报告](https://gitlab.eduxiji.net/educg-group-14238-914330/oskernel2022-npucore)提到的循环测试，就可以解决这个问题。 建议实现一个统一的测试框架，以单次开启内核尽量多执行测例的方式测试，这样既能加速测试运行，又能同时测试稳定性，又实现了 Qemu 和真机的统一，一举三得。

最好测试出错的时候直接由测试框架打印出一个复现脚本，出了错直接无脑复制粘贴就能再试。

[分支的 README](https://github.com/YdrMaster/zCore/blob/dev-xtask/xtask/README.md) 中增加了设计愿景。

实现了一部分 #287 。

缓存了更多东西 #288 。

我觉得测试集的运行逻辑也应该改改。现在每个测例都要启动 qemu、引导 zCore、运行测例、反馈结果，大量时间花在引导 zCore 上，尤其是 x86_64。如果做成启动一次 zCore 然后运行多个测例直到测试集结束或者内核崩溃呢？这样 x86_64 的运行时间估计能直接缩短 95%。如果不算超时全部测例只要运行两分钟，就算需要刷一刷也没什么关系。 #288 之后，大部分东西都缓存了，除了两个 x86_64 测试集需要 40 分钟，其他所有测试运行时间都在 10 分钟以内。如果把全部测试压到 10 分钟以内，测试框架就有足以支持日常使用的可用性了。

正在恢复 rootfs