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
