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 :)
