Re: [Xen-devel] Kbuild and Kconfig

[Doug Goldstein <cardoe@xxxxxxxxxx>]

On 9/3/15 10:00 AM, Jan Beulich wrote:
>>>> On 03.09.15 at 16:04, <cardoe@xxxxxxxxxx> wrote:
>> On 9/3/15 5:31 AM, Jan Beulich wrote:
>>>>>> On 02.09.15 at 19:50, <cardoe@xxxxxxxxxx> 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.
> 
> And note that I didn't say this "ordinary" way shouldn't be possible;
> in fact I meant it to be the default, with ./configure only allowed to
> control things that aren't already set in xen/.config (or whatever
> it's going to be named). The idea being that when you say
> "--without-<xyz>" and it affects both parts of the tree, you won't
> have to select the option another time in the hypervisor configure
> process.
> 
>>>> * 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.
> 
> I think where top level setting make sense (like enabling debug builds)
> they should be made work. For existing things at the top level not
> really belonging there I agree.
> 
> Jan
> 

Jan,

So locally I have in the xen/ (the hypervisor) "make menuconfig" working
but I'd likely address any concerns you might have upfront in the
patches. Effectively the xen/ directory now when built runs "make
defconfig" before it builds to generate the configuration. The default
configs I've used match what the tree currently contains. However you
expressed interest in having from the top level certain variables
controlled from that level like debug. I can pretty easily make it that
the effective command line is "make debug=y/1/n/0 defconfig" and that
would set CONFIG_DEBUG appropriately. If that's desired I can also
include that. Are there other flags that it would be desirable to have
them controllable from the top level?

-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

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