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
> +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.
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
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?
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 [email protected] More majordomo
> info at http://vger.kernel.org/majordomo-info.html Please read the FAQ
> at http://www.tux.org/lkml/