From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Kbuild and Kconfig Date: Wed, 2 Sep 2015 19:29:40 +0100 Message-ID: <55E74014.7010500@citrix.com> References: <55E736C8.3050302@cardoe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55E736C8.3050302@cardoe.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: Doug Goldstein , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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 (I cant immediately see how any of this would be usefully applied to docs/). Therefore, so long as the eventual plan doesn't preclude this (and it doesn't appear to), I have no specific concerns with this proposal. I will defer to your judgement as to which is the correct path to take to end up with a Kconfig system, as you clearly have more experience than I have in this area. If that means doing both Kconfig and Kbuild at the same time as it is less net work, then fine. (I will certainly be happier with a more Kbuild-like system where I can sensibly do out-of-tree builds). ~Andrew