I know that this response should be on linux-kernel-daydreams
instead of linux-kernel-hard-workers, but...
I disagree with the position, "init can't be replaced". We
can borrow a concept from one of the high-reliability operating
systems o the '70s (Tandem's, I think), and have a "standby init"
process, ready to take over when the real "init" dies.
How would this work? The standaby init process, when started,
would register itself (through some suitable API) as a "standby init"
with the kernel. This could be generalised to a queue of standby
init processes, if desired. When init fails, the kernel would make
the (first) standby init process the new init process and notify it of
the change (through some suitable API) (note: the new init process
should be notified of its new init-hood *before* it starts to receive
init-type work, if at all possible). Perhaps the old, dead init could
be attached to the new init for debugging?
What would the new init do? It might print a message and
*gracefully* shut down the system (including application-specific
shutdown), or it might print some debugging messages and continue, or
it might start a vigorous self-check. What to do is really a policy
issue, and the standby init process, as I've outlined it above, allows
the user to select policy outside the kernel context (whic I'm sure we
agree is often an attractive option).
It must be recognized (better still, documented :-) that the
kinds of events that are likely to kill a well-written init process ae
also likely to clobber any standby init process. This is a
best-effort solution, not a 100% guarantee. Nonetheless, I think that
this is a situation in which we ought to give the user lots of rope,
and let them hang the system themselves. ;-)
Finally, as with most things Linux, the surest way for this
feature to be implemented is for someone to take this project to
their heart, post a patch, and actively champion it.
Craig Milo Rogers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/