Re: Kbuild and Kconfig

[Doug Goldstein <cardoe@cardoe.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2951 bytes --]

On 9/3/15 4:56 AM, 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.
> 
> Ian.
> 
> 

So with my initial approach of targeting the xen/ directory how you
described it is how it would work. The optional items would be separate
and I really think in a lot of cases they are separate like you
describe. (e.g. turn off XSM in the hypervisor but not in the tools and
the tools gracefully handle that).

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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