>> [ Side note : panicking when process 1 exits is a *very* silly thing >> for the kernel to do. Process 1 exiting, instead of being forbidden, >> should mean the end of the machine's life cycle, and the kernel should >> either halt, reboot, or even kexec something else, depending on process >> 1's exit code. But that is totally off-topic. ] > > I suspect there might be ugly race conditions in this case (in the > window between process 1 ceasing to exist and the system shutting > down or doing whatever)
Race conditions ? The semantics I'm suggesting are perfectly clear and atomic. Process 1 exits -> the kernel reads its exit code and performs a reboot(), poweroff() or kexec() system call, *at once*. > and there's also the issue of special-casing > who gets the SIGCHLD, and whether process 1 would be zombie, etc. when > init terminates. If process 1 terminates, UNIX semantics are done for. From the moment process 1 dies and the system enters kernel space to handle this death, the system never goes into user space again. Just like it is doing today, except it should reboot or halt instead of panic. There is no no such thing as a SIGCHLD or a zombie for process 1. -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
