关于boot option

[hypocrasy]

如果没有boot option，做CI测试时应该采取什么样的策略来获取os的执行状态呢，就像这个issue中提到的是否能保持os的在线
#286 (comment)

[shzhxh]

如果没有启动选项，让测例直接在shell里运行就行。但如果遇到崩溃或超时，要让内核能重启。
这里有一个在shell里运行测例的脚本：https://github.com/rcore-os/zCore/blob/net-testing/scripts/baremetal-libc-test-d1.py
这个脚本的背景是：zCore运行在D1开发板上，脚本通过串口和D1交互，但没有实现让zCore可以自动重启的功能。

[YdrMaster]

如果没有boot option，做CI测试时应该采取什么样的策略来获取os的执行状态呢，就像这个issue中提到的是否能保持os的在线 #286 (comment)

我的设想是通过 qemu 外设来传递信息。一种可能的方案是内核中增加一个进程通过 qemu 外设向外发送心跳和测例运行状态，外部测试框架监控这些信息，察觉测例失败、超时、内核崩溃等事件，通过开关 qemu 控制测例运行。

[YdrMaster]

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

[YdrMaster]

目前内核的测试在 Qemu 上和真机上是不一致的。

在 Qemu 上采取了简单的方式：为每个测例都开启一个独立的 Qemu 实例，运行完后无论成功失败，立即关机。这个做法在真机上是不可行的，因为真机启动不好控制，重启还可能需要掉电，无法自动进行。所以真机上必须每次启动都执行尽量多的测例，当且仅当无法继续测试时才关机。无法继续测试的情况包括没有更多测例或内核已经崩溃。实际上，既然这是唯一可行的方案，就一定会被采用，OS 比赛内核赛道的测试就是这样执行的，所有参赛的内核也都支持这样运行测例。

实际上，现在的 qemu 测试还有另一个问题：只能测试功能，无法测试稳定性问题，比如内存泄漏，因为每个测例完成后都会重启清除状态。如果一次运行多个测例甚至支持这个报告提到的循环测试，就可以解决这个问题。

建议实现一个统一的测试框架，以单次开启内核尽量多执行测例的方式测试，这样既能加速测试运行，又能同时测试稳定性，又实现了 Qemu 和真机的统一，一举三得。

[elliott10]

对于里面提到的真机板子crash如何重启的这个功能，在fu740上可以通过额外接到GPIO口来控制reset的功能，应该可以作为一个参照
https://github.com/nubbi3/graduation-projects/blob/2022-06-15/Log/FU740%E7%B7%9A%E4%B8%8A%E7%B3%BB%E7%B5%B1%E6%90%AD%E5%BB%BA%E6%96%87%E6%AA%94.md#fu740