On 9 Nov 2002, Eric W. Biederman wrote:
>
> What I was thinking is that the process would for and exec
> something like "/etc/rc 6" or maybe "/etc/rc 7" to be clean.
> And that script would do all of the user space shutdown.
>
> No need to mlock any pages, or hack init, or special hacks.
> Just user space cleanly shutting itself down.
Ehh.. You do realize that the above doesn't actually _work_?
First off, "all the user space shutdown" includes things like turning off
networking. Oh, and if you're on a NFS-root system, your process is now
officially _toast_.
Unless you do the "mlockall()" etc that you seem to think that you don't
need, that is.
In other words: oh, yes, you do need those mlock() calls.
And never mind the fact that everybody has a slightly different "init"
setup, so executing "/etc/rc 6" may not actually _do_ anything. So now you
need to learn about all the different initscripts, and get that right.
And btw, thanks to the mlockall() requirements, you actually end up
pinning more memory than the two-phase approach ever would have done while
you do all this.
You then need to do the pre-loading anyway for the "kexec-on-panic" case
that you think is so different (I don't understand why you think a reboot
is different from another reboot, but whatever). So now you not only
maintain something that knows about many different init scripts and uses
more memory, it also ends up doing the same reboot thing at least two
different ways.
-- meanwhile, in another universe --
With the two-way separation, you don't have any of these problems. Your
maintenance nightmare has now become _one_ added script:
/etc/rc.d/rc6.d/K00loadkernel
and people using other init script variants can trivially add a script to
match their setup. Done. No maintenance headache, no special init
binaries, no torn-out-hair.
And by adding a startup script, you can have a _different_ small "debug
dump" kernel loaded early, so that if the machine reboots without going
through the controlled sequence, it will automatically boot into that
debug kernel..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:19 EST