Re: [Xen-devel] Kbuild and Kconfig

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel