Re: Kbuild and Kconfig

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 02/09/2015 21:28, Doug Goldstein wrote:
> On 9/2/15 1:29 PM, 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 (I cant immediately see how any of this
>> would be usefully applied to docs/).
>>
>> Therefore, so long as the eventual plan doesn't preclude this (and it
>> doesn't appear to), I have no specific concerns with this proposal.
>>
>> I will defer to your judgement as to which is the correct path to take
>> to end up with a Kconfig system, as you clearly have more experience
>> than I have in this area.  If that means doing both Kconfig and Kbuild
>> at the same time as it is less net work, then fine.  (I will certainly
>> be happier with a more Kbuild-like system where I can sensibly do
>> out-of-tree builds).
>>
>> ~Andrew
>>
> Long term, yes we can tackle tools and stubdoms as well but initially I
> was trying to eat the elephant one bite at a time. My idea was that we
> would do xen/ first and you would have to go into that directory and run
> "make defconfig/menuconfig/config/etc && make" inside that directory.
> Once the other directories got converted we could move the setup to the
> top level and include xen/, tools/, stubdom/. It should be mostly a
> mechanical move.
>
>

Sounds reasonable.

~Andrew