Re: [Xen-devel] Kbuild and Kconfig

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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

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