[Bug] qemu-virt64-riscv failed to execute poweroff

[unicornx]

RT-Thread Version

master

Hardware Type/Architectures

bsp/qemu-virt64-riscv

Develop Toolchain

GCC

Describe the bug

qemu-virt64-riscv 环境，smart 版本，带 ext4 文件系统启动后，执行 poweroff 原来是可以关机退出 qemu 的，但是从 944f3d05b508d5eaeaabd8f5d2964847c80dbc3e 开始，执行 poweroff 失败报错：

/ # poweroff
poweroff: (null): Operation not permitted

请问这是期望效果还是 944f3d05b508 改出了什么问题？

补充一下：这个问题其实应该不仅仅是在 qemu 上，在 duo 上测试也是类似现象。

Other additional context

No response

[polarvid]

期望效果。因为 poweroff 操作需要适配正确的流程。原来那套关机操作从系统角度并不“正确”。如果直接这么继续，会让用户误认为这个操作是合理的，继续不作为。所以直接封死了，抛出“Operation not permitted”。

P.S. 1 根据题主提供的有限信息，猜测是在这里返回的，不一定就是这样。如果题主补充其他信息，可以进一步确定。 P.S. 2 此处更新后，Busybox 也需要重新同步到新的 release（如果题主也是使用基于 BB 的根文件系统），userapps 主线上应该还没更新。

[BernardXiong]

这部分是否是需要先做file system umount，然后再做reset/shutdown流程？而file system unmount流程可以是统一抽象出来的，而reset/shutdown流程则可以由不同的bsp来实现？

[polarvid]

#9654 的设计思路是将关机分为两种

1. 硬件下电。最原始的方式，直接用内核态命令解释器等方式触发事件，调用 rt_hw_cpu_* API 实施硬件下电。
2. 软件下电。考量到系统软硬件语义的下电。依赖 init 进程提供的 Runtime Environment 完成应用层（应用通过配置或脚本定义操作、文件系统 umount 等等），和 smart 内核通过 syscall 提供的内核层（进程清理，缓冲写回等等）下电。再由 smart 内核触发事件，进入硬件层下电（不单单是一个 rt_hw_cpu_shutdown，还应该包括停止设备操作，断开连接…… 对于类似 hdd 的设备来说，这些流程有现实意义）。

#9654 修改的 shutdown 系统调用，不再接受没有配置 RUNTIME，暴力进入硬件下电的选项。因为这不安全，却让用户没有感知。和直接拔插座相比没多大区别。如果对用户来说关机是必要的，那么他应该配置 RUNTIME。反之，对他来说 shutdown 这个命令都不需要存在。写出来也只是浪费存储资源，不符合可持续性与环境友好的软件开发准则[1]。

[1] https://spectrum.ieee.org/green-software

[unicornx]

看上去和 #9761 是重复了。