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.
