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

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

[Matt D. Robinson]

This patch adds the ability to configure crash dumps in the
kernel, including optional compression mechanisms and loading
of network crash dump capabilities.

 arch/i386/config.in |    7 +++++++
 lib/Config.in       |    2 ++
 2 files changed, 9 insertions(+)

diff -Naur linux-2.5.44.orig/arch/i386/config.in linux-2.5.44.lkcd/arch/i386/config.in
--- linux-2.5.44.orig/arch/i386/config.in	Fri Oct 18 21:01:21 2002
+++ linux-2.5.44.lkcd/arch/i386/config.in	Sat Oct 19 12:39:15 2002
@@ -455,6 +455,13 @@
    dep_bool 'Software Suspend (EXPERIMENTAL)' CONFIG_SOFTWARE_SUSPEND $CONFIG_PM
 fi
 
+tristate 'Crash dump support' CONFIG_CRASH_DUMP
+if [ "$CONFIG_CRASH_DUMP" != "n" ]; then
+   dep_tristate '  Crash dump block device driver' CONFIG_CRASH_DUMP_BLOCKDEV $CONFIG_CRASH_DUMP
+   dep_tristate '  Crash dump RLE compression' CONFIG_CRASH_DUMP_COMPRESS_RLE $CONFIG_CRASH_DUMP
+   dep_tristate '  Crash dump GZIP compression' CONFIG_CRASH_DUMP_COMPRESS_GZIP $CONFIG_CRASH_DUMP
+fi
+
 bool 'Kernel debugging' CONFIG_DEBUG_KERNEL
 if [ "$CONFIG_DEBUG_KERNEL" != "n" ]; then
    bool '  Check for stack overflows' CONFIG_DEBUG_STACKOVERFLOW
diff -Naur linux-2.5.44.orig/lib/Config.in linux-2.5.44.lkcd/lib/Config.in
--- linux-2.5.44.orig/lib/Config.in	Fri Oct 18 21:01:10 2002
+++ linux-2.5.44.lkcd/lib/Config.in	Sat Oct 19 12:39:15 2002
@@ -26,10 +26,12 @@
 fi
 
 if [ "$CONFIG_PPP_DEFLATE" = "y" -o \
+     "$CONFIG_CRASH_DUMP_COMPRESS_GZIP" = "y" -o \
      "$CONFIG_JFFS2_FS" = "y" ]; then
    define_tristate CONFIG_ZLIB_DEFLATE y
 else
   if [ "$CONFIG_PPP_DEFLATE" = "m" -o \
+       "$CONFIG_CRASH_DUMP_COMPRESS_GZIP" = "m" -o \
        "$CONFIG_JFFS2_FS" = "m" ]; then
      define_tristate CONFIG_ZLIB_DEFLATE m
   else

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

[Christoph Hellwig]

> +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.

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.

It's not much code either and the actual dump drivers stay modular.

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

[Matt D. Robinson]

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

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

[Christoph Hellwig]

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?

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

[Suparna Bhattacharya]

On Mon, 21 Oct 2002 19:13:16 +0530, 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.

The problem here is that dump_in_progress is set by the dump 
execution code which is invoked a little after this, and only
stays enabled as long as that function executes. Maybe what
you meant here is not dump_in_progress but something more like
dump_okay (which is currently a static in dump drivers code), 
or a check if the dump function is set, indicating that 
things are setup so that a dump would be taken ?

Regards
Suparna

> 
> 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.
> 
> It's not much code either and the actual dump drivers stay modular.
> 
> -
> 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/