[BusyBox] Randominit question:

[Rob Landley]

Okay, init's got some stuff like this:

>    new_action = calloc((size_t) (1), sizeof(struct init_action));
>    if (!new_action) {
>        message(LOG | CONSOLE, "Memory allocation failure");
>        loop_forever();
>    }

Which is obviously avoiding the use of xcalloc, because if it exits this 
causes a kernel panic.

Now here I am asking "okay, so why is "panic: tried to kill init" particulary 
worse than loop_forever? I don't think it'll drive stuff off the top of the 
screen, as this isn't a panic that causes a register dump.  And presumably, 
it flushes to the log happily.  And we DID call check_memory anyway to make 
sure we've got enough that this shouldn't be a problem unless they're forcing 
it to re-read inittab late in the game (which I'm not entirely certain is 
possible, but the signal handling's a bit of a mess still...)

The point is, init failing effectively IS a panic situation.  Why do we go to 
great lengths not to exit?

(P.S.  If you chroot into an environment that runs init, it screws up the 
console it's run on so badly that if you kill it from another window when the 
console prompt comes back it ignores everything you type.  (I eventually 
killed everything back until login respawned, and when I hit enter after my 
login name it printed ^M.  Now _that_ is horked.)

I haven't tried it on a pty (Konsole) yet...  That could be fun.  I want to be 
ready to reboot first if the sucker recycles a broken pty in a weird way on 
me...)

Rob
-- 
www.linucon.org: Linux Expo and Science Fiction Convention
October 8-10, 2004 in Austin Texas.  (I'm the con chair.)