>
> > + // umount -a
> > + // ???
> >
> > Do we really want to hard-reboot without remounting RO
> > or unmounting filesystems?
> >
I must expand "// ???" to be the real umounting. I got stuck here hesitating
whether to just spawn("umount -a") or try to reimplement umount -a by
hand... Next, kernel has SysRQ magic Alt+PrnScr+U sequence which, when
enabled, remounts all FSs RO. May be track it down to know which system call
is used and just issue it from runsvdir?
> What if user disagrees with our reboot sequence (needs bigger delays,
> > wants to free lop devices, etc?). Yes, he can code up "different reboot"
> > himself, as a shell script. But this exact *our* sequence can be set up
> > exactly the same way as a shell script, no need to patch runsvdir! Right?
Of course. But there are reasonable defaults, we should hardcode them and
then make user able to change them, as vanilla init does respecting shutdown
record. I use "exec runsvdir" at the end of my initramfs /init script to
make runsvdir true init (PID=1), so no return or custom scripting after
runsvdir is possible.
People who want custom actions should not send init a signal, but rather use
"sv exit ..." technique.
In order to facilitatte this, we just need to make sure
> we do not crash kernel by exiting. kernel doesn't like
> init exiting.
I think it is normal to have init exited and kernel just OOPSed...
How about attached patch?
Am trying...
--
Vladimir
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox
