From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v8 00/28] Kconfig conversion Date: Wed, 16 Dec 2015 10:41:07 +0000 Message-ID: <1450262467.4053.24.camel@citrix.com> References: <1450185206-14259-1-git-send-email-cardoe@cardoe.com> <567122D502000078000BFFCE@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <567122D502000078000BFFCE@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Doug Goldstein Cc: xen-devel@lists.xen.org, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Wed, 2015-12-16 at 00:37 -0700, Jan Beulich wrote: > > > > On 15.12.15 at 14:12, 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 > > 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.