On Mon, 21 Oct 2002, Christoph Hellwig wrote:
|>> +tristate 'Crash dump support' CONFIG_CRASH_DUMP
|>
|>I"m very unhappy with this beeing a tristate. We have the following
|>things depend on it either builtin or modular:
|>
|>(1) build Kerntypes
|>(2) do not send smp_stop_cpu
|>
|>and the following goes into dump.o:
|>
|>(3) dump_base.c
|>(4) dump_<arch>.c
|>
|>Of those (2) should be replaced by a dump_in_progress check so
|>that we poweroff even with dumping enabled, but not in progress.
There is the concept of non-distruptive dumping, which means
that you don't power off after a dump -- you keep running. In
other words, you can silence the system and then resume after
a dump is taken. It's a way of snapshotting the system state
which is possible today.
|>The question is whether we should make (1) unconditional either
|>or make it a separate bool (CONFIG_KERNELTYPES) so that that dump.o
|>could be load into any such kernel. But imho CONFIG_CRASH_DUMP
|>should just become a bool - this way dump_<arch>.c could be moved
|>into arch/<arch>/kernel and a lot of exports could be remove.
Wow ... we spent a ton of time moving all the code _out_ of the
arch directories as other kernel developers didn't want it there.
|>It's not much code either and the actual dump drivers stay modular.
I realize what you're asking for, but I'm not sure this is the
right way to implement it.
>From one perspective, the base dump driver is needed in order to
provide the upper level dumping capabilities as well as some of
the architecture-specific functionality. That said, however, if
you make it a bool, it's either on or off -- some people don't
want it in the kernel all the time, and shouldn't be required
to build in.
Maybe understanding that dumping can be non-disruptive changes
your opinion on this?
--Matt
-
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 : Wed Oct 23 2002 - 22:00:55 EST