[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Kbuild and Kconfig
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |