[PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU configurations

[Simon Horman]

On Tue, Feb 28, 2012 at 12:45:54PM -0800, Andrew Morton wrote:
> On Tue, 28 Feb 2012 09:40:57 +0000
> Will Deacon <will.deacon at arm.com> wrote:
> 
> > > > Still, you didn't answer my question!  What effect will the absence of
> > > > SYMBOL(swapper_pg_dir)= have upon downstream tools?  If "none" then
> > > > sure, let's remove it.  If "explosion" then we should emit a dummy
> > > > SYMBOL(swapper_pg_dir)=0 if CONFIG_NOMMU.
> > > 
> > > My thought was that the tools wouldn't be used in the CONFIG_NOMMU case (yet).
> > > But I take your point and I think the answer is that the fallout is unknown.
> > > Emitting a dummy value as you suggest seems reasonable.
> > 
> > The reason I didn't choose a dummy value to start with is because there are
> > plenty of other fields in the dump that are predicated on build-time CONFIG
> > options. Admittedly, some of these appear to be tagged with length
> > information, but consider these guys:
> > 
> > #ifndef CONFIG_NEED_MULTIPLE_NODES
> >         VMCOREINFO_SYMBOL(mem_map);
> >         VMCOREINFO_SYMBOL(contig_page_data);
> > #endif
> > 
> > Since the VMCOREINFO_SYMBOL macro stringifies the identifier, I guess userspace
> > has to treat the whole thing as a map, meaning that we *can* safely remove
> > elements from it.
> > 
> > So that's my speculation. Maybe somebody on the kexec list can confirm?
> 
> Yeah, I do think the chance of breaking anything here is small, and in
> the unlikely event that something *does* break then a) it deserved to
> break ;) and b) the user of that app will be a developer who can
> unbreak it.
> 
> Let's run with the patch as-is.

Fine by me :)