From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail.linuxfoundation.org ([140.211.169.12]) by casper.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1S2TwD-0006OB-OA for kexec@lists.infradead.org; Tue, 28 Feb 2012 20:46:24 +0000 Date: Tue, 28 Feb 2012 12:45:54 -0800 From: Andrew Morton Subject: Re: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU configurations Message-Id: <20120228124554.73b4f051.akpm@linux-foundation.org> In-Reply-To: <20120228094057.GC25625@mudshark.cambridge.arm.com> References: <20120226225842.GA23028@mudshark.cambridge.arm.com> <20120227003727.GA30831@verge.net.au> <20120227193054.GB24605@mudshark.cambridge.arm.com> <20120227235235.GE24159@verge.net.au> <20120227155643.cafb1c6d.akpm@linux-foundation.org> <20120228001928.GB11325@verge.net.au> <20120227162631.55cf014e.akpm@linux-foundation.org> <20120228005130.GE11325@verge.net.au> <20120227172555.46bffedf.akpm@linux-foundation.org> <20120228013526.GA7913@verge.net.au> <20120228094057.GC25625@mudshark.cambridge.arm.com> Mime-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kexec-bounces@lists.infradead.org Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Will Deacon Cc: Simon Horman , "kexec@lists.infradead.org" On Tue, 28 Feb 2012 09:40:57 +0000 Will Deacon 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. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec