strange CRASH_DUMP dependencies

strange CRASH_DUMP dependencies

[Adrian Bunk]

config CRASH_DUMP
	bool "kernel crash dumps (EXPERIMENTAL)"
	depends on EMBEDDED
	depends on EXPERIMENTAL
	depends on HIGHMEM
	help
	  Generate crash dump after being started by kexec.

Two questions:
- If it has any dependencies on kexec, why isn't there a dependency?
- Is there any sane reason for the dependency on EMBEDDED?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: strange CRASH_DUMP dependencies

[Vivek Goyal]

On Mon, Aug 22, 2005 at 12:53:10AM +0200, Adrian Bunk wrote:
> config CRASH_DUMP
> 	bool "kernel crash dumps (EXPERIMENTAL)"
> 	depends on EMBEDDED
> 	depends on EXPERIMENTAL
> 	depends on HIGHMEM
> 	help
> 	  Generate crash dump after being started by kexec.
> 
> Two questions:
> - If it has any dependencies on kexec, why isn't there a dependency?

crashdump has got dependency on kexec but not in the same kernel. What
I mean is that as of today two kernels are involved in this process. First
kernel is crashing kernel which should have enabled CONFIG_KEXEC and second
kernel (capture kernel) is one which captures the dump and should have
CONFIG_CRASH_DUMP enabled. Second kernel need not to have CONFIG_KEXEC
enabled for catpturing dump. Hence CRASH_DUMP is not directly dependent
on CONFIG_KEXEC.

> - Is there any sane reason for the dependency on EMBEDDED?
> 

I believe this was introduced because large servers can have huge amount
of memory (running into Tera Bytes) and saving all that memory might not be
practical. Hence it was perceived that until some filtering mechanism is
implemented, it is more suited for small systems.

Personally I think it can be gotten away with because as a developer I can
run gdb directly on /proc/vmcore and need not to save the whole memory hence
need not to restrict this feature only for small systems.

Eric, do you think otherwise?

Thanks
Vivek

Re: strange CRASH_DUMP dependencies

[Eric W. Biederman]

Vivek Goyal <vgoyal@in.ibm.com> writes:

> On Mon, Aug 22, 2005 at 12:53:10AM +0200, Adrian Bunk wrote:
>> config CRASH_DUMP
>> 	bool "kernel crash dumps (EXPERIMENTAL)"
>> 	depends on EMBEDDED
>> 	depends on EXPERIMENTAL
>> 	depends on HIGHMEM
>> 	help
>> 	  Generate crash dump after being started by kexec.
>> 
>> Two questions:
>> - If it has any dependencies on kexec, why isn't there a dependency?
>
> crashdump has got dependency on kexec but not in the same kernel. What
> I mean is that as of today two kernels are involved in this process. First
> kernel is crashing kernel which should have enabled CONFIG_KEXEC and second
> kernel (capture kernel) is one which captures the dump and should have
> CONFIG_CRASH_DUMP enabled. Second kernel need not to have CONFIG_KEXEC
> enabled for catpturing dump. Hence CRASH_DUMP is not directly dependent
> on CONFIG_KEXEC.
>
>> - Is there any sane reason for the dependency on EMBEDDED?
>> 
>
> I believe this was introduced because large servers can have huge amount
> of memory (running into Tera Bytes) and saving all that memory might not be
> practical. Hence it was perceived that until some filtering mechanism is
> implemented, it is more suited for small systems.
>
> Personally I think it can be gotten away with because as a developer I can
> run gdb directly on /proc/vmcore and need not to save the whole memory hence
> need not to restrict this feature only for small systems.
>
> Eric, do you think otherwise?

I would have to look again but I think the EMBEDDED dependency comes in
more from the code that runs the kernel at a different address.  But
the essence is not because the crash dump kernel is for small systems
(that isn't what embedded means anyway) but because at the moment you
can't reasonably have the crash dump kernel be a general purpose
kernel.

I have some patches which should use of a general purpose kernel.  I
need to find a few moments and get them into the -mm tree for further testing.

For most of the code under CONFIG_CRASH_DUMP my opinion is that all
that is really need is fix /dev/mem to be usable, and we can do most
if not all of the work in user space.  But as long as we are
communicating between the two kernels with a sane interface I really
don't care.

Eric

Re: strange CRASH_DUMP dependencies

[Adrian Bunk]

On Mon, Aug 22, 2005 at 11:53:02AM +0530, Vivek Goyal wrote:
> On Mon, Aug 22, 2005 at 12:53:10AM +0200, Adrian Bunk wrote:
> > config CRASH_DUMP
> > 	bool "kernel crash dumps (EXPERIMENTAL)"
> > 	depends on EMBEDDED
> > 	depends on EXPERIMENTAL
> > 	depends on HIGHMEM
> > 	help
> > 	  Generate crash dump after being started by kexec.
> > 
> > Two questions:
> > - If it has any dependencies on kexec, why isn't there a dependency?
> 
> crashdump has got dependency on kexec but not in the same kernel. What
> I mean is that as of today two kernels are involved in this process. First
> kernel is crashing kernel which should have enabled CONFIG_KEXEC and second
> kernel (capture kernel) is one which captures the dump and should have
> CONFIG_CRASH_DUMP enabled. Second kernel need not to have CONFIG_KEXEC
> enabled for catpturing dump. Hence CRASH_DUMP is not directly dependent
> on CONFIG_KEXEC.

Sounds reasonable.

> > - Is there any sane reason for the dependency on EMBEDDED?
> > 
> 
> I believe this was introduced because large servers can have huge amount
> of memory (running into Tera Bytes) and saving all that memory might not be
> practical. Hence it was perceived that until some filtering mechanism is
> implemented, it is more suited for small systems.
>...

It seems you have a wrong impression of what EMBEDDED in the kernel 
does.

There is _not_ a choice EMBEDDED/WORKSTATION/SERVER.

EMBEDDED is an option that shows "save space at any cost" options.

It allows you to tell gcc to generate slower but faster code or to 
deselect options in the "do this only if you _really_ know what you are 
doing" class.

> Thanks
> Vivek

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: strange CRASH_DUMP dependencies

[Eric W. Biederman]

Adrian Bunk <bunk@stusta.de> writes:

>> > - Is there any sane reason for the dependency on EMBEDDED?
>> > 
>> 
>> I believe this was introduced because large servers can have huge amount
>> of memory (running into Tera Bytes) and saving all that memory might not be
>> practical. Hence it was perceived that until some filtering mechanism is
>> implemented, it is more suited for small systems.
>>...
>
> It seems you have a wrong impression of what EMBEDDED in the kernel 
> does.
>
> There is _not_ a choice EMBEDDED/WORKSTATION/SERVER.
>
> EMBEDDED is an option that shows "save space at any cost" options.
>
> It allows you to tell gcc to generate slower but faster code or to 
> deselect options in the "do this only if you _really_ know what you are 
> doing" class.

And at the moment that is where building a crashdump capture kernel falls.
"do this only if you really know what you are doing". 

Eric

Re: strange CRASH_DUMP dependencies

[Vivek Goyal]

On Mon, Aug 22, 2005 at 10:44:17PM +0200, Adrian Bunk wrote:
> On Mon, Aug 22, 2005 at 11:53:02AM +0530, Vivek Goyal wrote:
> > On Mon, Aug 22, 2005 at 12:53:10AM +0200, Adrian Bunk wrote:
> > > config CRASH_DUMP
> > > 	bool "kernel crash dumps (EXPERIMENTAL)"
> > > 	depends on EMBEDDED
> > > 	depends on EXPERIMENTAL
> > > 	depends on HIGHMEM
> > > 	help
> > > 	  Generate crash dump after being started by kexec.
> > > 
> > > Two questions:
> > > - If it has any dependencies on kexec, why isn't there a dependency?
> > 
> > crashdump has got dependency on kexec but not in the same kernel. What
> > I mean is that as of today two kernels are involved in this process. First
> > kernel is crashing kernel which should have enabled CONFIG_KEXEC and second
> > kernel (capture kernel) is one which captures the dump and should have
> > CONFIG_CRASH_DUMP enabled. Second kernel need not to have CONFIG_KEXEC
> > enabled for catpturing dump. Hence CRASH_DUMP is not directly dependent
> > on CONFIG_KEXEC.
> 
> Sounds reasonable.
> 
> > > - Is there any sane reason for the dependency on EMBEDDED?
> > > 
> > 
> > I believe this was introduced because large servers can have huge amount
> > of memory (running into Tera Bytes) and saving all that memory might not be
> > practical. Hence it was perceived that until some filtering mechanism is
> > implemented, it is more suited for small systems.
> >...
> 
> It seems you have a wrong impression of what EMBEDDED in the kernel 
> does.
> 

Yes, I misunderstood it.

Thanks
Vivek