Thomas Renninger <trenn at suse.de> writes: > On Wednesday, February 06, 2013 03:39:50 PM Eric W. Biederman wrote: >> "H. Peter Anvin" <hpa at zytor.com> writes: >> >> 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. Only kexec-tools needs the functionality so no kernel level backporting is necessary. > 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. Way over complicated. kexec-tools can just stop passing the memmap= options entirely for every kernel. We have not actually identified a use that the kernel would make of the reserved areas. Comming up with a new mapping type is just hedging our bets in case there is a reason we want to know what is actually RAM at some point in the future. >> > 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, Eric
