Re: [PATCH v8 00/28] Kconfig conversion

From: Ian Campbell <ian.campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Doug Goldstein <cardoe@cardoe.com>
Cc: xen-devel@lists.xen.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH v8 00/28] Kconfig conversion
Date: Wed, 16 Dec 2015 10:41:07 +0000	[thread overview]
Message-ID: <1450262467.4053.24.camel@citrix.com> (raw)
In-Reply-To: <567122D502000078000BFFCE@prv-mh.provo.novell.com>

On Wed, 2015-12-16 at 00:37 -0700, Jan Beulich wrote:
> > > > On 15.12.15 at 14:12, <cardoe@cardoe.com> wrote:
> > The following series is a follow on to the Kconfig conversion patch
> > series.
> > There are still more components to convert however this is the bare
> > minimal
> > to get everything working and get the options out of the existing
> > makefiles.
> > 
> > The CONFIG_HAS_ variables are there to match the behavior of the Linux
> > CONFIG_HAVE_ variables. The purpose is to say that this
> > hardware/profile/env
> > supports this option while the CONFIG_ variable states that this option
> > was
> > requested on/off by user intervention.
> > 
> > Ultimately my goal is to allow for more parts of the hypervisor to be
> > turned
> > off at compile time and potentially make it easier to include more
> > experimental features by others which can be turned off by default.
> > Also to
> > provide the one true location for all possible knobs in the source
> > code.
> > 
> > The patch series can be grabbed at:
> > https://github.com/cardoe/xen/tree/kconfig_v8 
> > 
> > Change since v7:
> > - rebased on top of split out patches that have been merged
> > - functionally the behavior is identical mostly comment and variable
> > changes
> 
> Patches 1, 3, 4, 12, and 23-26 now also
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> I didn't check each of the patches, but with the XSM acks having
> come in, the main missing thing at this point for at least an initial
> part of the series to go in seem to be ARM side acks.

I've acked all the ARM ones I spotted based on diffstat, if I've missed
something or there was THE REST code where my input is needed the a pointer
would be appreciated.

However as I've just reported there is something broken with the overall
workflow (make defconfg + make doesn't seem to work for me), which I
obviously consider a blocker for actually applying, even if I happen to
have acked the patch which is responsible...

Ian.