Re: [Xen-devel] Kbuild and Kconfig

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.09.15 at 12:09, <tim@xxxxxxx> wrote:
> At 10:56 +0100 on 03 Sep (1441277769), Ian Campbell wrote:
>> 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.

I don't see why ./configure shouldn't be able to invoke the
configure mechanism in xen/, passing it appropriate overrides
based on the --disable settings it was handed.

I definitely agree with Ian that using a single mechanism for
both tools and hypervisor is rather not what we want (due to
the different nature of the two).

Jan


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