> In article <cistron.19990709142018.I400@mencheca.ch.genedata.com>,
> >I don't see why we need this in the kernel. Your distribution can
> >(as you evidently know) pass `init=/.sbi/init' to the kernel, so why
> >do we need this?
>
> Because init=/.sbi/init doesn't just start /.sbi/init as PID #1, it
> starts an _internal kernel init_ which keeps on respawning the program
> you pass to init= . That program doesn't have init-like properties
> (can be killed, is not PID #1).
>
Have you actually tried this? I assure you that there is no such thing
as an 'internal kernel init'. Look at the code. The task is started
with PID=1 and it does an execve("/sbin/init".....); or whatever was
entered on the command line like init=/bin/bash. Since this is an
execve, the executing code is replaced, all open files are retained,
and the PID remains the same.
Now, if you substitute /bin/bash as init, it does not trap a call to
exit(), so you can exit which is not what you would want init to do.
Further, the signals are not set up by the shell in the same way they
are set up by init so you will find that ^C doesn't work nor does
^S/^Q, etc.
If you mount the proc file-system, you will find that your shell is,
indeed, PID=1, and after mucking around, you can execute `exec /sbin/init`
and the system will start normally with the new (real) init overwriting
your shell, still retaining PID=1.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.6 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
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/