[PATCH 0/3] Cleanup kdump memmap= passing and e820 usage

[Thomas Renninger]

On Wednesday, February 06, 2013 03:39:50 PM Eric W. Biederman wrote:
> "H. Peter Anvin" <hpa at zytor.com> writes:
...
> >> My real preference would be to define a command line option that will
> >> work on all architectures that implement kdump, as the craskernel option
> >> does.  Unfortunately it looks like that ship has sailed, and there isn't
> >> enough desire to fix this to come up with a generic option that will
> >> work on more than just x86.  But if we could get past the kernel
> >> versioning and figure out a arch-generic solution it might be worth it.
> > 
> > What would that option look like?
> 
> Probably something like "usemem=<size>@<addr>,..."
If the e820 table approach is taken, x86 would not need any such
parameter at all anymore?
All the memmap= stuff can vanish only the elfcorehdr= param remains.
 
...
> >> The existing e820 handling for unknown type is much much better.  It
> >> just treats them as reserved and goes about it's merry way.
If the new kdump type is treated as reserved and things work out,
I agree that this would be the most elegant approach, especially also
for backporting etc.
In a kernel which has the patch/functionality backported I would do
it like this then:
  - If the special kdump e820 type shows up, all memmap options from
    memmap=exactmap on are ignored and the kexec-tools passed
    e820 table is used just as it is.
    -> This would still allow e820 modifcations through memmap=
    if passed manually for debugging, they just have to show up before
    the kexec-tools generated ones. Anyway, I will also send a patch
    how I think this can be backported and still work with old and new
    kexec-tools versions.

> > It sounds like this is the way to go.
> 
> It certainly looks good.  We still need someone with the time to write
> the patch and test it.

I try to find time for this early next week to code something together and
already give it some testing, but I cannot promise anything.

Thanks everybody for the help to find the best solution,

  Thomas