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