Re: [Xen-devel] Kbuild and Kconfig

[Doug Goldstein <cardoe@xxxxxxxxxx>]

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.


-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

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