Calling the reboot(2) system call directly skips a lot of steps that are performed by the reboot program to ensure that processes are stopped and disks get synced. Testing shows that skipping these steps results in misbehaviour such as SSH sessions towards the nsh system hanging instead of being terminated cleanly by sshd. It can even result in a visit to ddb(4) due to unflushed vnodes hitting a KASSERT during reboot (clearly a kernel-side bug, but anyway it would hurt if triggered in production).
Rather than reimplementing all the logic of the reboot program in nsh just call the reboot binary. This seems like the most robust approach to me.
While here, add a powerdown command which runs halt -p and update the man page to explain the differences between regular halt and halt -p.
Calling the reboot(2) system call directly skips a lot of steps that are performed by the reboot program to ensure that processes are stopped and disks get synced. Testing shows that skipping these steps results in misbehaviour such as SSH sessions towards the nsh system hanging instead of being terminated cleanly by sshd. It can even result in a visit to ddb(4) due to unflushed vnodes hitting a KASSERT during reboot (clearly a kernel-side bug, but anyway it would hurt if triggered in production).
Rather than reimplementing all the logic of the reboot program in nsh just call the reboot binary. This seems like the most robust approach to me.
While here, add a powerdown command which runs halt -p and update the man page to explain the differences between regular halt and halt -p.