Re: Kbuild and Kconfig

[Tim Deegan <tim@xen.org>]

At 10:56 +0100 on 03 Sep (1441277769), 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.

This is as it should be, but I can see the argument for cutting out
whole features at build time, from both sides.  If I were embedding
Xen in an appliance, or building my own cloud, I'd be very happy to
./configure --disable all sorts of things from the entire build,
without having to figure out how to disable each feature twice.

Cheers,

Tim.