From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Kbuild and Kconfig Date: Fri, 4 Sep 2015 11:59:50 +0100 Message-ID: <55E979A6.3060308@citrix.com> References: <55E736C8.3050302@cardoe.com> <55E74014.7010500@citrix.com> <1441274169.26292.323.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1441274169.26292.323.camel@citrix.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: Ian Campbell , Doug Goldstein , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 03/09/15 10:56, Ian Campbell wrote: > On Wed, 2015-09-02 at 19:29 +0100, Andrew Cooper wrote: >> On 02/09/15 18:50, Doug Goldstein wrote: >>> I just wanted to bring this to a top level post since Jonathan >>> Creekmore >>> and myself have talked with a few maintainers in different threads and >>> on IRC about potentially using Kconfig and/or Kbuild for Xen. Basically >>> I would like to get a rough idea on what the Xen community wants the >>> system to look like before starting work on it to both save myself time >>> and save maintainers review cycles. So that being said rough proposal >>> as >>> follows: >>> >>> * target only the xen/ directory tree (i.e. not the toolstack, stubdoms >>> or docs) >>> * split top level config bits to not affect xen/ tree (currently only >>> XSM_ENABLE / FLASK_ENABLE do) >>> * convert xen/ to Kbuild first and merge this in (since Kconfig relies >>> on Kbuild-y bits which can be undone but if we're going to go to Kbuild >>> in the end why undo it and then redo it) >>> * convert existing xen/ config bits into Kconfig and merge that in >>> >>> Jonathan and I, in a former life, converted a project to Kbuild and >>> Kconfig successfully. I have looked at starting with >>> https://github.com/masahir0y/kbuild_skeleton while the tree is fairly >>> old it does separate out the build bits from the Linux specific bits >>> pretty nicely while removing module support which arguably is the most >>> complicated part. Alternatively we could start with Linux 4.2 if that's >>> more desirable. >> Thinking longterm, it would be nice to have xen, tools and stubdoms >> covered by a system like this > Is the proposal here then to abandon autoconf for the tools subtree in > favour of Kconfig? Or maybe to somehow hybridize autoconf (for e.g. library > and feature detection) with Kconfig (for user selection of options)? I'm > not sure how I feel about either of those approaches, they certainly both > need careful consideration, and the second in particular regarding the > interactions... > > FWIW it seems to me that the link between things which are optional in Xen > and which are optional in the tools is (or should be) pretty loose. i.e. > the tools today _always_ support XSM and correctly handle the errors from > Xen if it is not enabled there. Personally I think this is the right way to > do things. Likewise Xen doesn't care if the tools have particular opinions > on the qemu to use or whatever. > > IOW I'm not sure have xen and tools use a common .config would make sense. autoconf and Kconfig do two different things. Kconfig is of no use working out where $(libdir) should go, and ./configure --with-X --without-Y --with-Z has nothing on menuconfig for selecting what to build. if `make` does an implicit `make silentdefaultconfig` given no other information (to avoid a situation where using two configuration mechanisms is mandatory to get anything to build), then I don't see a problem with the two systems living together. ~Andrew