Re: Kbuild and Kconfig

[Doug Goldstein <cardoe@cardoe.com>]

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

On 9/3/15 5:31 AM, Jan Beulich wrote:
>>>> On 02.09.15 at 19:50, <cardoe@cardoe.com> wrote:
>> * target only the xen/ directory tree (i.e. not the toolstack, stubdoms
>> or docs)
> 
> As just said in another reply, allowing for ./configure to pass down
> options to the configure mechanism in xen/ would seem desirable (as
> long as configuring in xen/ alone would still work).

My concern would be that the ./configure options would be pretty
unwieldy. e.g.

./configure --without-kexec --without-xenlinux --with-schedule=credit2

You would effectively have to write a script to contain what your
"distro" (e.g. XenServer, Ubuntu with Xen, Amazon's build) wants.
However the Linux kernel has a nice way to pass around a defconfig
and/or .config files to ensure your build always behaves the same. Users
also have an easy way to see what new options have been added since
their .config was generated but autoconf does not have that.

> 
>> * split top level config bits to not affect xen/ tree (currently only
>> XSM_ENABLE / FLASK_ENABLE do)
> 
> As already said by someone else, this shouldn't be necessary. In fact
> I would hope there's (other than debug-build-or-not) no top level
> setting affecting both tools and hypervisor.

In the case of XSM_ENABLE and FLASK_ENABLE which are at the top level
they do affect both the tools/ directory and the xen/ directory but in
two totally different ways. For the tools side XSM is always enabled no
matter the setting but setting either of those to 'n' results in the
Flask policy not being built. For the xen/ directory it appears to
disable XSM support. Hence why I argue that not having top level
settings would be clearer from a usage standpoint.

> 
>> * 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)
> 
> To be honest I'm not convinced we want to pull in Kbuild as a whole.
> Achieving the ability to do out-of-tree builds (viewed as desirable
> by Andrew, and I've also long been meaning to see whether this
> could be made work, as that's also my preferred build setup in other
> projects) should be possible without importing everything (and
> perhaps even without importing anything).
> 
> Jan
> 

I can certainly go that route. The xen/ directory already uses Kbuild's
grandfather with a lot of customization so it probably wouldn't be that
world changing but like I said I can avoid it.

-- 
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