Re: [PATCH] 2.5.44: lkcd (7/9): dump configuration

[Christoph Hellwig <hch@sgi.com>]

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?