Re: Kbuild and Kconfig

[Ian Campbell <ian.campbell@citrix.com>]

On Fri, 2015-09-04 at 11:59 +0100, Andrew Cooper wrote:
> 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.

I, obviously, am aware of this.

> Kconfig is of no use working out where $(libdir) should go,

Indeed.

>  and 
> ./configure --with-X --without-Y --with-Z has nothing on menuconfig for 
> selecting what to build.

It can and is used to do so though, so we have two tools which can do some
of the same things, regardless of which one is better at any individual
thing.

> 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.

Nonetheless, I would like to see an explicit proposal for how they are
going to sanely and safely coexist, since AFAIK this is not something
others have done and I think the interactions need to be considered
carefully.

(also, none of this has any bearing on "I'm not sure have xen and tools use
a common .config would make sense" which what you appear to have replied
to).