On Mon, Oct 21, 2002 at 01:48:51PM -0700, Matt D. Robinson wrote:
> 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.
I don't see the relation of that to always disabling smp_send_stop()
in panic(). You only want to disable it if doing a dump, right?
> 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.
Hmm. It certainbly is arch-specific..
> 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.
Well, any chance you could get rid of the remaining
CONFIG_CRASH_DUMP || CONFIG_CRASH_DUMP_MODULE ifdefs when
keeping it as tristate? So that I can just load the module
into any kernel?
-
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