On Thursday, January 31, 2013 01:15:34 AM Thomas Renninger wrote:
> On Wednesday, January 30, 2013 02:29:04 PM Eric W. Biederman wrote:
> > "H. Peter Anvin" <hpa at zytor.com> writes:
> > > On 01/30/2013 01:57 PM, Eric W. Biederman wrote:
> > >>> Yes, those seem to be the options, and we're currently discussing which
> > >>> one.
> > >>>
> > >>> The second seems to make more sense to me. The kexec tools build the
> > >>> memory map anyway, and it makes sense to me at least to just build a
> > >>> memory map with the appropriate regions marked as a dumpable type.
> > >>
> > >> This dumpable type doesn't make sense to me. Are you suggesting making
> > >> regions that are memory but that we should not use a special memory
> > >> type?
> > >
> > > Yes.
> > >
> > >> I think I would prefer that to call that new type RESERVED_MEM or
> > >> RESERVED_CACHABLE. Being more specific is fine but dumpable certainly
> > >> doesn't bring to mind what we are saying. Especially since we already
> > >> communicate which areas were memory to the last kernel in an
> > >> architecture generic format.
> > >
> > > I was thinking that marking them differently might help debugging, at
> > > least, but yes, we can have a RESERVED_MEM type.
> > >
> > > However, Thomas does have a point that the current use of fairly small
> > > positive values for Linux-defined types is a bad idea. We should use
> > > negative types, or at least something north of 0x40000000 or so.
> >
> > Yes. It doesn't much matter in the kernel but when it because part of
> > the ABI it is a real issue.
> That's one point (self made up e820 type should better be kept kernel
> internal).
There is another important point, why the command line approach
should be preferred:
Backward compatibility and the ability to backport the whole stuff to
fix mmconf in kdump which would be nice for example for SLES11.
kexec-tools can detect the kernel version of the kernel which is loaded
as kdump/crash kernel. If its version is:
"$MAINLINE_VERSION_THE_CHANGE_GETS_INTRODUCED"
or newer, things are fine.
But if the kernel version is older, there is no way for kexec-tools to
find out whether the older kernel may have the feature included.
That's bad!
In case of the command line apprach kexec-tools can pass the whole memmap=
mess as passed before, plus the new format: memmap=kdump_reserve_usable,X at Y.
In older kernels the newly formatted string will get passed to:
memmparse("kdump_reserve_usable,X at Y")
and the memmap early_param function will return with -EINVAL:
mem_size = memparse(p, &p);
if (p == oldp)
return -EINVAL;
Ok, the kdump kernel which does not have the stuff backported would issue a:
printk(KERN_WARNING "Malformed early option '%s'\n", param);
which could get ignored. I guess this is fine compared to any other backport
nightmare approach.
Thomas
