[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140613101713.GD4751@pd.tnic>
Date: Fri, 13 Jun 2014 12:17:13 +0200
From: Borislav Petkov <bp@...en8.de>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
ebiederm@...ssion.com, hpa@...or.com, mjg59@...f.ucam.org,
greg@...ah.com, jkosina@...e.cz, dyoung@...hat.com,
chaowang@...hat.com, bhe@...hat.com, akpm@...ux-foundation.org
Subject: Re: [PATCH 09/13] purgatory: Core purgatory functionality
On Fri, Jun 06, 2014 at 03:51:04PM -0400, Vivek Goyal wrote:
> On Thu, Jun 05, 2014 at 10:05:23PM +0200, Borislav Petkov wrote:
>
> [..]
> > > @@ -249,6 +254,7 @@ archclean:
> > > $(Q)rm -rf $(objtree)/arch/x86_64
> > > $(Q)$(MAKE) $(clean)=$(boot)
> > > $(Q)$(MAKE) $(clean)=arch/x86/tools
> >
> > ifeq ($(CONFIG_KEXEC),y)
> > $(Q)$(MAKE) $(clean)=arch/x86/purgatory
> > endif
>
> Hmm.., is it strictly required? I am wondering what happens if I build
> a kernel with CONFIG_KEXEC=y, then set CONFIG_KEXEC=n and do "make clean".
Try it - it works here.
> I think I will still like any files in arch/x86/purgatory to be cleaned
> despite the fact that CONFIG_KEXEC=n. Isn't it?
Yep, that works. Conversely, we don't want people who haven't enabled
KEXEC ever to have unrelated cleanup delay.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists