Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Ian Campbell]

On Tue, 2015-12-08 at 18:04 +, Andrew Cooper wrote:
> On 08/12/15 17:59, Doug Goldstein wrote:
> > On 12/8/15 8:25 AM, Jan Beulich wrote:
> > > > > > On 08.12.15 at 15:16,  wrote:
> > > > On 12/8/15 1:32 AM, Jan Beulich wrote:
> > > > > > > > On 07.12.15 at 22:27,  wrote:
> > > > > > On 12/3/15 2:57 AM, Jan Beulich wrote:
> > > > > > > > > > On 03.12.15 at 01:34,  wrote:
> > > > > > > > On 12/1/15 5:22 AM, Jan Beulich wrote:
> > > > > > > > > > > > On 30.11.15 at 18:53,  wrote:
> > > > > > > > > > On 11/30/15 8:36 AM, Jan Beulich wrote:
> > > > > > > > > > > > > > On 24.11.15 at 18:51, 
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > +config ARCH_DEFCONFIG
> > > > > > > > > > > > +   string
> > > > > > > > > > > > +   default
> > > > > > > > > > > > "arch/x86/configs/x86_64_defconfig"
> > > > > > > > > > > x86_defconfig perhaps?
> > > > > > > > > > No. I was told to drop support for x86 entirely in an
> > > > > > > > > > earlier review.
> > > > > > > > > > Its not possible to configure for 32-bit x86 in v6.
> > > > > > > > > x86 != 32-bit. I think you're mixing this up with ix86 or
> > > > > > > > > x86-32.
> > > > > > > > > Here I consider x86 as to basic architecture without any
> > > > > > > > > particular bit width in mind.
> > > > > > > > ok. Well the syntax is still
> > > > > > > > "arch/SUBARCH/configs/ARCH_defconfig" so
> > > > > > > > the original is correct. There is no defconfig for the
> > > > > > > > ambiguous x86
> > > > > > > > family. You're either building for x86_64 or x86_32 (which
> > > > > > > > I referred to
> > > > > > > > as x86 in my original response).
> > > > > > > > 
> > > > > > > > This defconfig is for the 64-bit architecture of x86
> > > > > > > > (x86_64) and there
> > > > > > > > for its named correctly.
> > > > > > > But there is no x86_32 architecture form the hypervisor
> > > > > > > build's
> > > > > > > point of view, and hence x86 isn't ambiguous. In fact the
> > > > > > > mid-term
> > > > > > > plan is to remove leftovers of references to x86_64 (like the
> > > > > > > arch/x86/x86_64/ or include/asm-x86/x86_64/ directories)
> > > > > > > where
> > > > > > > possible. The only place they need to be kept are in the
> > > > > > > public
> > > > > > > interface.
> > > > > > That's fine but you don't build things for "x86". You build
> > > > > > them for
> > > > > > "x86_64". XEN_TARGET_ARCH takes in "x86_64".
> > > > > The XEN_TARGET_ARCH value is of no interest here. The only fact
> > > > > that I care about is that there's only one x86 configuration, and
> > > > > hence I can't see why it shouldn't be named x86_defconfig.
> > > > This is just how the upstream stuff works. Are we forking
> > > > upstream's
> > > > kconfig just so we can call it "x86" instead of "x86_64"?
> > > I don't think using
> > > 
> > > config ARCH_DEFCONFIG
> > >   string
> > >   default "arch/x86/configs/x86_defconfig"
> > > 
> > > instead of
> > > 
> > > config ARCH_DEFCONFIG
> > >   string
> > >   default "arch/x86/configs/x86_64_defconfig"
> > > 
> > > in a Kconfig file of ours is a fork. Or am I overlooking some other
> > > aspect?
> > > 
> > > Jan
> > > 
> > Its not that simple. When you run "make defconfig" it will default to
> > using "arch/$(SRCARCH)/configs/$(ARCH)_defconfig". Where SRCARCH =
> > TARGET_ARCH and ARCH = TARGET_SUBARCH = XEN_TARGET_ARCH. So to use real
> > values from the documentation how to build Xen:
> > 
> > - XEN_TARGET_ARCH=x86_64 make defconfig
> > - XEN_TARGET_ARCH=arm32 make defconfig
> > - XEN_TARGET_ARCH=arm64 make defconfig
> > 
> > The result is things build correctly. To make the variable build ups
> > change for x86 vs arm would require us to fork
> > xen/tools/kconfig/Makefile line 101 (potentially others).
> 
> Frankly, I don't think it is worth worrying that x86_64 could be
> shortened.  It is more important to reduce divergence from upstream
> Kconfig.

Agreed.

> After all, x86_128 is likely to come along sometime.

You owe me a new keyboard and a new cup of coffee.

Ian.

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

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Doug Goldstein]

On 12/8/15 1:32 AM, Jan Beulich wrote:
 On 07.12.15 at 22:27,  wrote:
>> On 12/3/15 2:57 AM, Jan Beulich wrote:
>> On 03.12.15 at 01:34,  wrote:
 On 12/1/15 5:22 AM, Jan Beulich wrote:
 On 30.11.15 at 18:53,  wrote:
>> On 11/30/15 8:36 AM, Jan Beulich wrote:
>> On 24.11.15 at 18:51,  wrote:
 +config ARCH_DEFCONFIG
 +  string
 +  default "arch/x86/configs/x86_64_defconfig"
>>>
>>> x86_defconfig perhaps?
>>
>> No. I was told to drop support for x86 entirely in an earlier review.
>> Its not possible to configure for 32-bit x86 in v6.
>
> x86 != 32-bit. I think you're mixing this up with ix86 or x86-32.
> Here I consider x86 as to basic architecture without any
> particular bit width in mind.

 ok. Well the syntax is still "arch/SUBARCH/configs/ARCH_defconfig" so
 the original is correct. There is no defconfig for the ambiguous x86
 family. You're either building for x86_64 or x86_32 (which I referred to
 as x86 in my original response).

 This defconfig is for the 64-bit architecture of x86 (x86_64) and there
 for its named correctly.
>>>
>>> But there is no x86_32 architecture form the hypervisor build's
>>> point of view, and hence x86 isn't ambiguous. In fact the mid-term
>>> plan is to remove leftovers of references to x86_64 (like the
>>> arch/x86/x86_64/ or include/asm-x86/x86_64/ directories) where
>>> possible. The only place they need to be kept are in the public
>>> interface.
>>
>> That's fine but you don't build things for "x86". You build them for
>> "x86_64". XEN_TARGET_ARCH takes in "x86_64".
> 
> The XEN_TARGET_ARCH value is of no interest here. The only fact
> that I care about is that there's only one x86 configuration, and
> hence I can't see why it shouldn't be named x86_defconfig.
> 
> Jan
> 

This is just how the upstream stuff works. Are we forking upstream's
kconfig just so we can call it "x86" instead of "x86_64"?

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Jan Beulich]

>>> On 08.12.15 at 15:16,  wrote:
> On 12/8/15 1:32 AM, Jan Beulich wrote:
> On 07.12.15 at 22:27,  wrote:
>>> On 12/3/15 2:57 AM, Jan Beulich wrote:
>>> On 03.12.15 at 01:34,  wrote:
> On 12/1/15 5:22 AM, Jan Beulich wrote:
> On 30.11.15 at 18:53,  wrote:
>>> On 11/30/15 8:36 AM, Jan Beulich wrote:
>>> On 24.11.15 at 18:51,  wrote:
> +config ARCH_DEFCONFIG
> + string
> + default "arch/x86/configs/x86_64_defconfig"

 x86_defconfig perhaps?
>>>
>>> No. I was told to drop support for x86 entirely in an earlier review.
>>> Its not possible to configure for 32-bit x86 in v6.
>>
>> x86 != 32-bit. I think you're mixing this up with ix86 or x86-32.
>> Here I consider x86 as to basic architecture without any
>> particular bit width in mind.
>
> ok. Well the syntax is still "arch/SUBARCH/configs/ARCH_defconfig" so
> the original is correct. There is no defconfig for the ambiguous x86
> family. You're either building for x86_64 or x86_32 (which I referred to
> as x86 in my original response).
>
> This defconfig is for the 64-bit architecture of x86 (x86_64) and there
> for its named correctly.

 But there is no x86_32 architecture form the hypervisor build's
 point of view, and hence x86 isn't ambiguous. In fact the mid-term
 plan is to remove leftovers of references to x86_64 (like the
 arch/x86/x86_64/ or include/asm-x86/x86_64/ directories) where
 possible. The only place they need to be kept are in the public
 interface.
>>>
>>> That's fine but you don't build things for "x86". You build them for
>>> "x86_64". XEN_TARGET_ARCH takes in "x86_64".
>> 
>> The XEN_TARGET_ARCH value is of no interest here. The only fact
>> that I care about is that there's only one x86 configuration, and
>> hence I can't see why it shouldn't be named x86_defconfig.
> 
> This is just how the upstream stuff works. Are we forking upstream's
> kconfig just so we can call it "x86" instead of "x86_64"?

I don't think using

config ARCH_DEFCONFIG
string
default "arch/x86/configs/x86_defconfig"

instead of

config ARCH_DEFCONFIG
string
default "arch/x86/configs/x86_64_defconfig"

in a Kconfig file of ours is a fork. Or am I overlooking some other
aspect?

Jan


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

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Doug Goldstein]

On 12/8/15 8:25 AM, Jan Beulich wrote:
 On 08.12.15 at 15:16,  wrote:
>> On 12/8/15 1:32 AM, Jan Beulich wrote:
>> On 07.12.15 at 22:27,  wrote:
 On 12/3/15 2:57 AM, Jan Beulich wrote:
 On 03.12.15 at 01:34,  wrote:
>> On 12/1/15 5:22 AM, Jan Beulich wrote:
>> On 30.11.15 at 18:53,  wrote:
 On 11/30/15 8:36 AM, Jan Beulich wrote:
 On 24.11.15 at 18:51,  wrote:
>> +config ARCH_DEFCONFIG
>> +string
>> +default "arch/x86/configs/x86_64_defconfig"
>
> x86_defconfig perhaps?

 No. I was told to drop support for x86 entirely in an earlier review.
 Its not possible to configure for 32-bit x86 in v6.
>>>
>>> x86 != 32-bit. I think you're mixing this up with ix86 or x86-32.
>>> Here I consider x86 as to basic architecture without any
>>> particular bit width in mind.
>>
>> ok. Well the syntax is still "arch/SUBARCH/configs/ARCH_defconfig" so
>> the original is correct. There is no defconfig for the ambiguous x86
>> family. You're either building for x86_64 or x86_32 (which I referred to
>> as x86 in my original response).
>>
>> This defconfig is for the 64-bit architecture of x86 (x86_64) and there
>> for its named correctly.
>
> But there is no x86_32 architecture form the hypervisor build's
> point of view, and hence x86 isn't ambiguous. In fact the mid-term
> plan is to remove leftovers of references to x86_64 (like the
> arch/x86/x86_64/ or include/asm-x86/x86_64/ directories) where
> possible. The only place they need to be kept are in the public
> interface.

 That's fine but you don't build things for "x86". You build them for
 "x86_64". XEN_TARGET_ARCH takes in "x86_64".
>>>
>>> The XEN_TARGET_ARCH value is of no interest here. The only fact
>>> that I care about is that there's only one x86 configuration, and
>>> hence I can't see why it shouldn't be named x86_defconfig.
>>
>> This is just how the upstream stuff works. Are we forking upstream's
>> kconfig just so we can call it "x86" instead of "x86_64"?
> 
> I don't think using
> 
> config ARCH_DEFCONFIG
>   string
>   default "arch/x86/configs/x86_defconfig"
> 
> instead of
> 
> config ARCH_DEFCONFIG
>   string
>   default "arch/x86/configs/x86_64_defconfig"
> 
> in a Kconfig file of ours is a fork. Or am I overlooking some other
> aspect?
> 
> Jan
> 

Its not that simple. When you run "make defconfig" it will default to
using "arch/$(SRCARCH)/configs/$(ARCH)_defconfig". Where SRCARCH =
TARGET_ARCH and ARCH = TARGET_SUBARCH = XEN_TARGET_ARCH. So to use real
values from the documentation how to build Xen:

- XEN_TARGET_ARCH=x86_64 make defconfig
- XEN_TARGET_ARCH=arm32 make defconfig
- XEN_TARGET_ARCH=arm64 make defconfig

The result is things build correctly. To make the variable build ups
change for x86 vs arm would require us to fork
xen/tools/kconfig/Makefile line 101 (potentially others).

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Andrew Cooper]

On 08/12/15 17:59, Doug Goldstein wrote:
> On 12/8/15 8:25 AM, Jan Beulich wrote:
> On 08.12.15 at 15:16,  wrote:
>>> On 12/8/15 1:32 AM, Jan Beulich wrote:
>>> On 07.12.15 at 22:27,  wrote:
> On 12/3/15 2:57 AM, Jan Beulich wrote:
> On 03.12.15 at 01:34,  wrote:
>>> On 12/1/15 5:22 AM, Jan Beulich wrote:
>>> On 30.11.15 at 18:53,  wrote:
> On 11/30/15 8:36 AM, Jan Beulich wrote:
> On 24.11.15 at 18:51,  wrote:
>>> +config ARCH_DEFCONFIG
>>> +   string
>>> +   default "arch/x86/configs/x86_64_defconfig"
>> x86_defconfig perhaps?
> No. I was told to drop support for x86 entirely in an earlier review.
> Its not possible to configure for 32-bit x86 in v6.
 x86 != 32-bit. I think you're mixing this up with ix86 or x86-32.
 Here I consider x86 as to basic architecture without any
 particular bit width in mind.
>>> ok. Well the syntax is still "arch/SUBARCH/configs/ARCH_defconfig" so
>>> the original is correct. There is no defconfig for the ambiguous x86
>>> family. You're either building for x86_64 or x86_32 (which I referred to
>>> as x86 in my original response).
>>>
>>> This defconfig is for the 64-bit architecture of x86 (x86_64) and there
>>> for its named correctly.
>> But there is no x86_32 architecture form the hypervisor build's
>> point of view, and hence x86 isn't ambiguous. In fact the mid-term
>> plan is to remove leftovers of references to x86_64 (like the
>> arch/x86/x86_64/ or include/asm-x86/x86_64/ directories) where
>> possible. The only place they need to be kept are in the public
>> interface.
> That's fine but you don't build things for "x86". You build them for
> "x86_64". XEN_TARGET_ARCH takes in "x86_64".
 The XEN_TARGET_ARCH value is of no interest here. The only fact
 that I care about is that there's only one x86 configuration, and
 hence I can't see why it shouldn't be named x86_defconfig.
>>> This is just how the upstream stuff works. Are we forking upstream's
>>> kconfig just so we can call it "x86" instead of "x86_64"?
>> I don't think using
>>
>> config ARCH_DEFCONFIG
>>  string
>>  default "arch/x86/configs/x86_defconfig"
>>
>> instead of
>>
>> config ARCH_DEFCONFIG
>>  string
>>  default "arch/x86/configs/x86_64_defconfig"
>>
>> in a Kconfig file of ours is a fork. Or am I overlooking some other
>> aspect?
>>
>> Jan
>>
> Its not that simple. When you run "make defconfig" it will default to
> using "arch/$(SRCARCH)/configs/$(ARCH)_defconfig". Where SRCARCH =
> TARGET_ARCH and ARCH = TARGET_SUBARCH = XEN_TARGET_ARCH. So to use real
> values from the documentation how to build Xen:
>
> - XEN_TARGET_ARCH=x86_64 make defconfig
> - XEN_TARGET_ARCH=arm32 make defconfig
> - XEN_TARGET_ARCH=arm64 make defconfig
>
> The result is things build correctly. To make the variable build ups
> change for x86 vs arm would require us to fork
> xen/tools/kconfig/Makefile line 101 (potentially others).

Frankly, I don't think it is worth worrying that x86_64 could be
shortened.  It is more important to reduce divergence from upstream Kconfig.

After all, x86_128 is likely to come along sometime.

~Andrew

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

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Jan Beulich]

>>> On 07.12.15 at 22:27,  wrote:
> On 12/3/15 2:57 AM, Jan Beulich wrote:
> On 03.12.15 at 01:34,  wrote:
>>> On 12/1/15 5:22 AM, Jan Beulich wrote:
>>> On 30.11.15 at 18:53,  wrote:
> On 11/30/15 8:36 AM, Jan Beulich wrote:
> On 24.11.15 at 18:51,  wrote:
>>> +config ARCH_DEFCONFIG
>>> +   string
>>> +   default "arch/x86/configs/x86_64_defconfig"
>>
>> x86_defconfig perhaps?
>
> No. I was told to drop support for x86 entirely in an earlier review.
> Its not possible to configure for 32-bit x86 in v6.

 x86 != 32-bit. I think you're mixing this up with ix86 or x86-32.
 Here I consider x86 as to basic architecture without any
 particular bit width in mind.
>>>
>>> ok. Well the syntax is still "arch/SUBARCH/configs/ARCH_defconfig" so
>>> the original is correct. There is no defconfig for the ambiguous x86
>>> family. You're either building for x86_64 or x86_32 (which I referred to
>>> as x86 in my original response).
>>>
>>> This defconfig is for the 64-bit architecture of x86 (x86_64) and there
>>> for its named correctly.
>> 
>> But there is no x86_32 architecture form the hypervisor build's
>> point of view, and hence x86 isn't ambiguous. In fact the mid-term
>> plan is to remove leftovers of references to x86_64 (like the
>> arch/x86/x86_64/ or include/asm-x86/x86_64/ directories) where
>> possible. The only place they need to be kept are in the public
>> interface.
> 
> That's fine but you don't build things for "x86". You build them for
> "x86_64". XEN_TARGET_ARCH takes in "x86_64".

The XEN_TARGET_ARCH value is of no interest here. The only fact
that I care about is that there's only one x86 configuration, and
hence I can't see why it shouldn't be named x86_defconfig.

Jan


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

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Doug Goldstein]

On 12/3/15 2:57 AM, Jan Beulich wrote:
 On 03.12.15 at 01:34,  wrote:
>> On 12/1/15 5:22 AM, Jan Beulich wrote:
>> On 30.11.15 at 18:53,  wrote:
 On 11/30/15 8:36 AM, Jan Beulich wrote:
 On 24.11.15 at 18:51,  wrote:
>> +mainmenu "Xen/$SRCARCH $XEN_FULLVERSION Configuration"
>> +
>> +config SRCARCH
>> +string
>> +option env="SRCARCH"
>> +
>> +config ARCH
>> +string
>> +option env="ARCH"
>> +
>> +source "arch/$SRCARCH/Kconfig"
>> +
>> +config XEN_FULLVERSION
>> +string
>> +option env="XEN_FULLVERSION"
>> +
>> +config DEFCONFIG_LIST
>> +string
>> +option defconfig_list
>> +default "$ARCH_DEFCONFIG"
>> +default "arch/$SRCARCH/defconfig"
>
> Linux'es variant has just SRCARCH and the source directive. Why
> do we need so much more here? In any even I again think you
> should at least briefly explain any extensions you do in the commit
> message.

 I'm not understanding the question here. Linux has 5 items in their
 list. The last two are identical to the 2 that I retained. Given other
 evolutions of the patchset I can drop the last one and keep it as just
 $ARCH_DEFCONFIG since I've always got that defined for arm and x86.
>>>
>>> Oh, the context was ambiguous: The comment related to everything
>>> quoted, not just the last option. I.e. I'm being irritated by there being
>>> quite a few more config options here compared to Linux.
>>
>> So all these items are in Linux. And they seem to actually be necessary.
>> You'll just find them in different files (e.g. init/Kconfig) that I
>> didn't import because we really didn't need them for anything.
> 
> Okay, this makes sense. Remains the question on the
> XEN_FULLVERSION name: Doesn't this collide with the identically
> named make variable? Or is it intentionally named the same? In
> which case - what's the purpose? There's no
> CONFIG_KERNELVERSION resulting from this in Linux (which seems
> in line with documentation).

This is intentional. Its for when you run "make {menu,n,g,x}config" and
it'll show the version info at the top. It also puts the version info as
a comment inside the .config. Just cosmetic stuff.

> 
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -17,6 +17,9 @@ export XEN_ROOT := $(BASEDIR)/..
>>  
>>  EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
>>  
>> +# Don't break if the build process wasn't called from the top level
>> +XEN_TARGET_ARCH ?= $(shell uname -m)
>
> I don't see the need for this. We already require setting this on the
> command line when invoking a build process bypassing the top level
> directory. Later in the series, when actually using the produced
> xen/.config, I could see this becoming a nice enhancement (by
> reading the value from the file).

 One of the early on reviews told me it was not required (and I can
 confirm that I can run "git clean -xdf && cd xen && make" and it will
 build). This change makes that behavior still work.
>>>
>>> Yes, non-cross builds of course have been working without setting
>>> that variable. I was (not clearly enough) referring to cross builds,
>>> including hypervisor builds on ix86 distros (which I consider at best
>>> kind of cross, but would really deem to be native with there not
>>> being any 32-bit hypervisor anymore).
>>>
>>> So can you clarify what exactly breaks in which way without this
>>> change?
>>
>> The ability to "git clone git://xen && cd xen/xen && make" because I
>> couldn't pick the correct defconfig to use. See the rules just below
>> this reply in xen/Makefile where they are used.
> 
> Okay. But - does "uname -m" really produce e.g. "arm32" and "arm64"
> respectively, and not, as I would expect, "armv..." and "aarch64"?
> See the setup of XEN_COMPILE_ARCH in ./Config.mk.

I've switched to pulling in Config.mk

> 
>> @@ -216,3 +220,16 @@ FORCE:
>>  
>>  %/: FORCE
>>  $(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o
>> +
>> +kconfig := silentoldconfig oldconfig config menuconfig defconfig \
>> +nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig
>> +.PHONY: $(kconfig)
>> +$(kconfig):
>> +$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
>> ARCH=$(XEN_TARGET_ARCH) $@
>> +
>> +$(BASEDIR)/include/config/%.conf: 
>> $(BASEDIR)/include/config/auto.conf.cmd
>> +$(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
>> ARCH=$(XEN_TARGET_ARCH) silentoldconfig
>
> Okay, I have found the Linux original to this and it's the same there,
> but I'd like to ask anyway: How can this work without $* getting
> passed on?

 silentoldconfig is the step that actually takes the .config and
 generates out all the 

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Jan Beulich]

>>> On 03.12.15 at 01:34,  wrote:
> On 12/1/15 5:22 AM, Jan Beulich wrote:
> On 30.11.15 at 18:53,  wrote:
>>> On 11/30/15 8:36 AM, Jan Beulich wrote:
>>> On 24.11.15 at 18:51,  wrote:
> +mainmenu "Xen/$SRCARCH $XEN_FULLVERSION Configuration"
> +
> +config SRCARCH
> + string
> + option env="SRCARCH"
> +
> +config ARCH
> + string
> + option env="ARCH"
> +
> +source "arch/$SRCARCH/Kconfig"
> +
> +config XEN_FULLVERSION
> + string
> + option env="XEN_FULLVERSION"
> +
> +config DEFCONFIG_LIST
> + string
> + option defconfig_list
> + default "$ARCH_DEFCONFIG"
> + default "arch/$SRCARCH/defconfig"

 Linux'es variant has just SRCARCH and the source directive. Why
 do we need so much more here? In any even I again think you
 should at least briefly explain any extensions you do in the commit
 message.
>>>
>>> I'm not understanding the question here. Linux has 5 items in their
>>> list. The last two are identical to the 2 that I retained. Given other
>>> evolutions of the patchset I can drop the last one and keep it as just
>>> $ARCH_DEFCONFIG since I've always got that defined for arm and x86.
>> 
>> Oh, the context was ambiguous: The comment related to everything
>> quoted, not just the last option. I.e. I'm being irritated by there being
>> quite a few more config options here compared to Linux.
> 
> So all these items are in Linux. And they seem to actually be necessary.
> You'll just find them in different files (e.g. init/Kconfig) that I
> didn't import because we really didn't need them for anything.

Okay, this makes sense. Remains the question on the
XEN_FULLVERSION name: Doesn't this collide with the identically
named make variable? Or is it intentionally named the same? In
which case - what's the purpose? There's no
CONFIG_KERNELVERSION resulting from this in Linux (which seems
in line with documentation).

> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -17,6 +17,9 @@ export XEN_ROOT := $(BASEDIR)/..
>  
>  EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
>  
> +# Don't break if the build process wasn't called from the top level
> +XEN_TARGET_ARCH ?= $(shell uname -m)

 I don't see the need for this. We already require setting this on the
 command line when invoking a build process bypassing the top level
 directory. Later in the series, when actually using the produced
 xen/.config, I could see this becoming a nice enhancement (by
 reading the value from the file).
>>>
>>> One of the early on reviews told me it was not required (and I can
>>> confirm that I can run "git clean -xdf && cd xen && make" and it will
>>> build). This change makes that behavior still work.
>> 
>> Yes, non-cross builds of course have been working without setting
>> that variable. I was (not clearly enough) referring to cross builds,
>> including hypervisor builds on ix86 distros (which I consider at best
>> kind of cross, but would really deem to be native with there not
>> being any 32-bit hypervisor anymore).
>> 
>> So can you clarify what exactly breaks in which way without this
>> change?
> 
> The ability to "git clone git://xen && cd xen/xen && make" because I
> couldn't pick the correct defconfig to use. See the rules just below
> this reply in xen/Makefile where they are used.

Okay. But - does "uname -m" really produce e.g. "arm32" and "arm64"
respectively, and not, as I would expect, "armv..." and "aarch64"?
See the setup of XEN_COMPILE_ARCH in ./Config.mk.

> @@ -216,3 +220,16 @@ FORCE:
>  
>  %/: FORCE
>   $(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o
> +
> +kconfig := silentoldconfig oldconfig config menuconfig defconfig \
> + nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig
> +.PHONY: $(kconfig)
> +$(kconfig):
> + $(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) 
> $@
> +
> +$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd
> + $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
> ARCH=$(XEN_TARGET_ARCH) silentoldconfig

 Okay, I have found the Linux original to this and it's the same there,
 but I'd like to ask anyway: How can this work without $* getting
 passed on?
>>>
>>> silentoldconfig is the step that actually takes the .config and
>>> generates out all the files like auto.conf and generated/config.h It
>>> should be in xen/scripts/kconfig/Makefile.linux I believe.
>> 
>> Not sure what you're trying to tell me, but in any event I don't see
>> this to answer the question.
> 
> So maybe I'm not understanding your question. I don't understand why $*
> would need to be passed on. The target "silentoldconfig" in the kconfig
> Makefile takes care of building all of the files that the rule could
> match. That's what I tried to say in my original response. 

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Doug Goldstein]

On 12/1/15 5:22 AM, Jan Beulich wrote:
 On 30.11.15 at 18:53,  wrote:
>> On 11/30/15 8:36 AM, Jan Beulich wrote:
>> On 24.11.15 at 18:51,  wrote:
 +mainmenu "Xen/$SRCARCH $XEN_FULLVERSION Configuration"
 +
 +config SRCARCH
 +  string
 +  option env="SRCARCH"
 +
 +config ARCH
 +  string
 +  option env="ARCH"
 +
 +source "arch/$SRCARCH/Kconfig"
 +
 +config XEN_FULLVERSION
 +  string
 +  option env="XEN_FULLVERSION"
 +
 +config DEFCONFIG_LIST
 +  string
 +  option defconfig_list
 +  default "$ARCH_DEFCONFIG"
 +  default "arch/$SRCARCH/defconfig"
>>>
>>> Linux'es variant has just SRCARCH and the source directive. Why
>>> do we need so much more here? In any even I again think you
>>> should at least briefly explain any extensions you do in the commit
>>> message.
>>
>> I'm not understanding the question here. Linux has 5 items in their
>> list. The last two are identical to the 2 that I retained. Given other
>> evolutions of the patchset I can drop the last one and keep it as just
>> $ARCH_DEFCONFIG since I've always got that defined for arm and x86.
> 
> Oh, the context was ambiguous: The comment related to everything
> quoted, not just the last option. I.e. I'm being irritated by there being
> quite a few more config options here compared to Linux.

So all these items are in Linux. And they seem to actually be necessary.
You'll just find them in different files (e.g. init/Kconfig) that I
didn't import because we really didn't need them for anything. Xen has
SRCARCH and ARCH. (In fact Xen had SRCARCH in the Makefiles and I
removed it in a patch about a month ago since it wasn't used and was
inconsistent with XEN_TARGET_ARCH/XEN_TARGET_SUBARCH. SRCARCH is the
general platform (e.g. x86/arm) while ARCH is the specific variant
(x86_64/arm64/arm32). Unfortunately a bunch of the machinery in kconfig
utilities these variables and when I tried to switch to
XEN_TARGET_ARCH/XEN_TARGET_SUBARCH it caused me to have to change the
pieces I copied from Linux (this is being discussed separately in this
patch series as undesirable by Ian).


> 
 --- a/xen/Makefile
 +++ b/xen/Makefile
 @@ -17,6 +17,9 @@ export XEN_ROOT := $(BASEDIR)/..
  
  EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
  
 +# Don't break if the build process wasn't called from the top level
 +XEN_TARGET_ARCH ?= $(shell uname -m)
>>>
>>> I don't see the need for this. We already require setting this on the
>>> command line when invoking a build process bypassing the top level
>>> directory. Later in the series, when actually using the produced
>>> xen/.config, I could see this becoming a nice enhancement (by
>>> reading the value from the file).
>>
>> One of the early on reviews told me it was not required (and I can
>> confirm that I can run "git clean -xdf && cd xen && make" and it will
>> build). This change makes that behavior still work.
> 
> Yes, non-cross builds of course have been working without setting
> that variable. I was (not clearly enough) referring to cross builds,
> including hypervisor builds on ix86 distros (which I consider at best
> kind of cross, but would really deem to be native with there not
> being any 32-bit hypervisor anymore).
> 
> So can you clarify what exactly breaks in which way without this
> change?

The ability to "git clone git://xen && cd xen/xen && make" because I
couldn't pick the correct defconfig to use. See the rules just below
this reply in xen/Makefile where they are used.

> 
 @@ -216,3 +220,16 @@ FORCE:
  
  %/: FORCE
$(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o
 +
 +kconfig := silentoldconfig oldconfig config menuconfig defconfig \
 +  nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig
 +.PHONY: $(kconfig)
 +$(kconfig):
 +  $(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) 
 $@
 +
 +$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd
 +  $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
 ARCH=$(XEN_TARGET_ARCH) silentoldconfig
>>>
>>> Okay, I have found the Linux original to this and it's the same there,
>>> but I'd like to ask anyway: How can this work without $* getting
>>> passed on?
>>
>> silentoldconfig is the step that actually takes the .config and
>> generates out all the files like auto.conf and generated/config.h It
>> should be in xen/scripts/kconfig/Makefile.linux I believe.
> 
> Not sure what you're trying to tell me, but in any event I don't see
> this to answer the question.

So maybe I'm not understanding your question. I don't understand why $*
would need to be passed on. The target "silentoldconfig" in the kconfig
Makefile takes care of building all of the files that the rule could
match. That's what I tried to say in my original response. I believe
your point is that I would have to pass the target file on 

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Jan Beulich]

>>> On 30.11.15 at 18:53,  wrote:
> On 11/30/15 8:36 AM, Jan Beulich wrote:
> On 24.11.15 at 18:51,  wrote:
>>> +mainmenu "Xen/$SRCARCH $XEN_FULLVERSION Configuration"
>>> +
>>> +config SRCARCH
>>> +   string
>>> +   option env="SRCARCH"
>>> +
>>> +config ARCH
>>> +   string
>>> +   option env="ARCH"
>>> +
>>> +source "arch/$SRCARCH/Kconfig"
>>> +
>>> +config XEN_FULLVERSION
>>> +   string
>>> +   option env="XEN_FULLVERSION"
>>> +
>>> +config DEFCONFIG_LIST
>>> +   string
>>> +   option defconfig_list
>>> +   default "$ARCH_DEFCONFIG"
>>> +   default "arch/$SRCARCH/defconfig"
>> 
>> Linux'es variant has just SRCARCH and the source directive. Why
>> do we need so much more here? In any even I again think you
>> should at least briefly explain any extensions you do in the commit
>> message.
> 
> I'm not understanding the question here. Linux has 5 items in their
> list. The last two are identical to the 2 that I retained. Given other
> evolutions of the patchset I can drop the last one and keep it as just
> $ARCH_DEFCONFIG since I've always got that defined for arm and x86.

Oh, the context was ambiguous: The comment related to everything
quoted, not just the last option. I.e. I'm being irritated by there being
quite a few more config options here compared to Linux.

>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -17,6 +17,9 @@ export XEN_ROOT := $(BASEDIR)/..
>>>  
>>>  EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
>>>  
>>> +# Don't break if the build process wasn't called from the top level
>>> +XEN_TARGET_ARCH ?= $(shell uname -m)
>> 
>> I don't see the need for this. We already require setting this on the
>> command line when invoking a build process bypassing the top level
>> directory. Later in the series, when actually using the produced
>> xen/.config, I could see this becoming a nice enhancement (by
>> reading the value from the file).
> 
> One of the early on reviews told me it was not required (and I can
> confirm that I can run "git clean -xdf && cd xen && make" and it will
> build). This change makes that behavior still work.

Yes, non-cross builds of course have been working without setting
that variable. I was (not clearly enough) referring to cross builds,
including hypervisor builds on ix86 distros (which I consider at best
kind of cross, but would really deem to be native with there not
being any 32-bit hypervisor anymore).

So can you clarify what exactly breaks in which way without this
change?

>>> @@ -216,3 +220,16 @@ FORCE:
>>>  
>>>  %/: FORCE
>>> $(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o
>>> +
>>> +kconfig := silentoldconfig oldconfig config menuconfig defconfig \
>>> +   nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig
>>> +.PHONY: $(kconfig)
>>> +$(kconfig):
>>> +   $(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) 
>>> $@
>>> +
>>> +$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd
>>> +   $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
>>> ARCH=$(XEN_TARGET_ARCH) silentoldconfig
>> 
>> Okay, I have found the Linux original to this and it's the same there,
>> but I'd like to ask anyway: How can this work without $* getting
>> passed on?
> 
> silentoldconfig is the step that actually takes the .config and
> generates out all the files like auto.conf and generated/config.h It
> should be in xen/scripts/kconfig/Makefile.linux I believe.

Not sure what you're trying to tell me, but in any event I don't see
this to answer the question.

>>> +# Allow people to just run `make` as before and not force them to configure
>>> +$(BASEDIR)/.config $(BASEDIR)/include/config/auto.conf.cmd: ;
>>> +   $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
>>> ARCH=$(XEN_TARGET_ARCH) defconfig
>> 
>> Is this correct? If I have xen/.config but no
>> xen/include/config/auto.conf.cmd I surely don't want "defconfig" to
>> be run (unless "defconfig" honors xen/.config, in which case the
>> goal's name would be questionable)?
>> 
>> Also do you really need all the explicit $(BASEDIR) references in the
>> rules above?
> 
> I was asked to make the build work with out of tree builds and that's
> why I went this route. The rest of the Xen build system doesn't support
> out of tree builds so one can argue that's not needed.

That can't be right - $(BASEDIR) can't possibly refer to both the
source and object trees, yet the code above clearly references
both.

>>> --- /dev/null
>>> +++ b/xen/arch/arm/configs/arm32_defconfig
>>> @@ -0,0 +1 @@
>>> +CONFIG_64BIT=n
>>> diff --git a/xen/arch/arm/configs/arm64_defconfig 
>>> b/xen/arch/arm/configs/arm64_defconfig
>>> new file mode 100644
>>> index 000..e69de29
>> 
>> As said before I'm not really up to speed with defconfigs, but the
>> arm64 variant being empty but the arm32 one disabling 64BIT
>> seems backwards: You don't even have a choice on arm32.
> 
> I agree its squirrelly here. I believe I followed Linux and it only
> seems to come 

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Doug Goldstein]

On 11/30/15 8:36 AM, Jan Beulich wrote:
 On 24.11.15 at 18:51,  wrote:
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -217,6 +217,11 @@ tools/xentrace/tbctl
>>  tools/xentrace/xenctx
>>  tools/xentrace/xentrace
>>  xen/.banner
>> +xen/.config
>> +xen/.config.old
>> +xen/defconfig
>> +xen/**/*.cmd
>> +xen/**/modules.order
> 
> The last two seem rather dubious to me in our environment.
> 
>> @@ -239,6 +244,9 @@ xen/include/headers++.chk
>>  xen/include/asm
>>  xen/include/asm-*/asm-offsets.h
>>  xen/include/compat/*
>> +xen/include/config.h
> 
> Linux doesn't seem to generate a file like this. Is this perhaps a
> stale entry you're copying over?
> 
>> --- /dev/null
>> +++ b/xen/Kconfig
>> @@ -0,0 +1,26 @@
>> +#
>> +# For a description of the syntax of this configuration file,
>> +# see Documentation/kbuild/kconfig-language.txt from the Linux
> 
> This path needs fixing.
> 
>> +# kernel source tree.
>> +#
>> +mainmenu "Xen/$SRCARCH $XEN_FULLVERSION Configuration"
>> +
>> +config SRCARCH
>> +string
>> +option env="SRCARCH"
>> +
>> +config ARCH
>> +string
>> +option env="ARCH"
>> +
>> +source "arch/$SRCARCH/Kconfig"
>> +
>> +config XEN_FULLVERSION
>> +string
>> +option env="XEN_FULLVERSION"
>> +
>> +config DEFCONFIG_LIST
>> +string
>> +option defconfig_list
>> +default "$ARCH_DEFCONFIG"
>> +default "arch/$SRCARCH/defconfig"
> 
> Linux'es variant has just SRCARCH and the source directive. Why
> do we need so much more here? In any even I again think you
> should at least briefly explain any extensions you do in the commit
> message.

I'm not understanding the question here. Linux has 5 items in their
list. The last two are identical to the 2 that I retained. Given other
evolutions of the patchset I can drop the last one and keep it as just
$ARCH_DEFCONFIG since I've always got that defined for arm and x86.

> 
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -17,6 +17,9 @@ export XEN_ROOT := $(BASEDIR)/..
>>  
>>  EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
>>  
>> +# Don't break if the build process wasn't called from the top level
>> +XEN_TARGET_ARCH ?= $(shell uname -m)
> 
> I don't see the need for this. We already require setting this on the
> command line when invoking a build process bypassing the top level
> directory. Later in the series, when actually using the produced
> xen/.config, I could see this becoming a nice enhancement (by
> reading the value from the file).

One of the early on reviews told me it was not required (and I can
confirm that I can run "git clean -xdf && cd xen && make" and it will
build). This change makes that behavior still work.

> 
>> @@ -216,3 +220,16 @@ FORCE:
>>  
>>  %/: FORCE
>>  $(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o
>> +
>> +kconfig := silentoldconfig oldconfig config menuconfig defconfig \
>> +nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig
>> +.PHONY: $(kconfig)
>> +$(kconfig):
>> +$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) 
>> $@
>> +
>> +$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd
>> +$(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
>> ARCH=$(XEN_TARGET_ARCH) silentoldconfig
> 
> Okay, I have found the Linux original to this and it's the same there,
> but I'd like to ask anyway: How can this work without $* getting
> passed on?

silentoldconfig is the step that actually takes the .config and
generates out all the files like auto.conf and generated/config.h It
should be in xen/scripts/kconfig/Makefile.linux I believe.

> 
>> +# Allow people to just run `make` as before and not force them to configure
>> +$(BASEDIR)/.config $(BASEDIR)/include/config/auto.conf.cmd: ;
>> +$(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
>> ARCH=$(XEN_TARGET_ARCH) defconfig
> 
> Is this correct? If I have xen/.config but no
> xen/include/config/auto.conf.cmd I surely don't want "defconfig" to
> be run (unless "defconfig" honors xen/.config, in which case the
> goal's name would be questionable)?
> 
> Also do you really need all the explicit $(BASEDIR) references in the
> rules above?

I was asked to make the build work with out of tree builds and that's
why I went this route. The rest of the Xen build system doesn't support
out of tree builds so one can argue that's not needed.

> 
>> --- /dev/null
>> +++ b/xen/arch/arm/configs/arm32_defconfig
>> @@ -0,0 +1 @@
>> +CONFIG_64BIT=n
>> diff --git a/xen/arch/arm/configs/arm64_defconfig 
>> b/xen/arch/arm/configs/arm64_defconfig
>> new file mode 100644
>> index 000..e69de29
> 
> As said before I'm not really up to speed with defconfigs, but the
> arm64 variant being empty but the arm32 one disabling 64BIT
> seems backwards: You don't even have a choice on arm32.

I agree its squirrelly here. I believe I followed Linux and it only
seems to come into play when you don't specify you're target arch and
are running natively on the platform but want to build for the 

Re: [Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Jan Beulich]

>>> On 24.11.15 at 18:51,  wrote:
> --- a/.gitignore
> +++ b/.gitignore
> @@ -217,6 +217,11 @@ tools/xentrace/tbctl
>  tools/xentrace/xenctx
>  tools/xentrace/xentrace
>  xen/.banner
> +xen/.config
> +xen/.config.old
> +xen/defconfig
> +xen/**/*.cmd
> +xen/**/modules.order

The last two seem rather dubious to me in our environment.

> @@ -239,6 +244,9 @@ xen/include/headers++.chk
>  xen/include/asm
>  xen/include/asm-*/asm-offsets.h
>  xen/include/compat/*
> +xen/include/config.h

Linux doesn't seem to generate a file like this. Is this perhaps a
stale entry you're copying over?

> --- /dev/null
> +++ b/xen/Kconfig
> @@ -0,0 +1,26 @@
> +#
> +# For a description of the syntax of this configuration file,
> +# see Documentation/kbuild/kconfig-language.txt from the Linux

This path needs fixing.

> +# kernel source tree.
> +#
> +mainmenu "Xen/$SRCARCH $XEN_FULLVERSION Configuration"
> +
> +config SRCARCH
> + string
> + option env="SRCARCH"
> +
> +config ARCH
> + string
> + option env="ARCH"
> +
> +source "arch/$SRCARCH/Kconfig"
> +
> +config XEN_FULLVERSION
> + string
> + option env="XEN_FULLVERSION"
> +
> +config DEFCONFIG_LIST
> + string
> + option defconfig_list
> + default "$ARCH_DEFCONFIG"
> + default "arch/$SRCARCH/defconfig"

Linux'es variant has just SRCARCH and the source directive. Why
do we need so much more here? In any even I again think you
should at least briefly explain any extensions you do in the commit
message.

> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -17,6 +17,9 @@ export XEN_ROOT := $(BASEDIR)/..
>  
>  EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
>  
> +# Don't break if the build process wasn't called from the top level
> +XEN_TARGET_ARCH ?= $(shell uname -m)

I don't see the need for this. We already require setting this on the
command line when invoking a build process bypassing the top level
directory. Later in the series, when actually using the produced
xen/.config, I could see this becoming a nice enhancement (by
reading the value from the file).

> @@ -216,3 +220,16 @@ FORCE:
>  
>  %/: FORCE
>   $(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o
> +
> +kconfig := silentoldconfig oldconfig config menuconfig defconfig \
> + nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig
> +.PHONY: $(kconfig)
> +$(kconfig):
> + $(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) 
> $@
> +
> +$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd
> + $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
> ARCH=$(XEN_TARGET_ARCH) silentoldconfig

Okay, I have found the Linux original to this and it's the same there,
but I'd like to ask anyway: How can this work without $* getting
passed on?

> +# Allow people to just run `make` as before and not force them to configure
> +$(BASEDIR)/.config $(BASEDIR)/include/config/auto.conf.cmd: ;
> + $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
> ARCH=$(XEN_TARGET_ARCH) defconfig

Is this correct? If I have xen/.config but no
xen/include/config/auto.conf.cmd I surely don't want "defconfig" to
be run (unless "defconfig" honors xen/.config, in which case the
goal's name would be questionable)?

Also do you really need all the explicit $(BASEDIR) references in the
rules above?

> --- /dev/null
> +++ b/xen/arch/arm/configs/arm32_defconfig
> @@ -0,0 +1 @@
> +CONFIG_64BIT=n
> diff --git a/xen/arch/arm/configs/arm64_defconfig 
> b/xen/arch/arm/configs/arm64_defconfig
> new file mode 100644
> index 000..e69de29

As said before I'm not really up to speed with defconfigs, but the
arm64 variant being empty but the arm32 one disabling 64BIT
seems backwards: You don't even have a choice on arm32.

> --- /dev/null
> +++ b/xen/arch/x86/Kconfig
> @@ -0,0 +1,18 @@
> +config X86_64
> + def_bool y
> +
> +config X86
> + def_bool y
> + select HAS_GDBSX

Didn't you mean to convert HAS_* in subsequent patches?

Also - not 64BIT here, yet this - if added to ARM - should be added
here too so it can be used in common code.

> +config ARCH_DEFCONFIG
> + string
> + default "arch/x86/configs/x86_64_defconfig"

x86_defconfig perhaps?

> --- /dev/null
> +++ b/xen/scripts/kconfig/Makefile
> @@ -0,0 +1,77 @@
> +# xen/scripts/kconfig
> +
> +MAKEFLAGS += -rR

Why?

> +# default rule to do nothing
> +all:
> +
> +XEN_ROOT = $(CURDIR)/..
> +
> +# Xen doesn't have a silent build flag
> +quiet := silent_
> +Q := @
> +kecho := :
> +
> +# eventually you'll want to do out of tree builds
> +srctree = $(XEN_ROOT)/xen
> +objtree = $(srctree)
> +src := scripts/kconfig
> +obj := $(src)
> +KBUILD_SRC :=
> +
> +# handle functions (most of these lifted from different Linux makefiles
> +dot-target = $(dir $@).$(notdir $@)
> +depfile = $(subst $(comma),,$(dot-target).d)
> +basetarget = $(basename $(notdir $@))
> +cmd = $(cmd_$(1))
> +if_changed = $(if y, \
> + @set -e; \
> + $(cmd_$(1)); \
> + )
> +
> +if_changed_dep = $(if y, \
> + 

[Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Doug Goldstein]

Wire in the Kconfig build and makefile rules to be able to generate
valid configuration files to be used by the build process but don't
actually use the output for affecting the Xen build.

CC: Ian Campbell 
CC: Stefano Stabellini 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 .gitignore|  8 
 xen/Kconfig   | 26 
 xen/Makefile  | 17 
 xen/arch/arm/Kconfig  | 31 ++
 xen/arch/arm/configs/arm32_defconfig  |  1 +
 xen/arch/arm/configs/arm64_defconfig  |  0
 xen/arch/x86/Kconfig  | 18 
 xen/arch/x86/configs/x86_64_defconfig |  0
 xen/common/Kconfig|  4 ++
 xen/drivers/Kconfig   |  3 ++
 xen/scripts/kconfig/.gitignore|  3 ++
 xen/scripts/kconfig/Makefile  | 77 +++
 12 files changed, 188 insertions(+)
 create mode 100644 xen/Kconfig
 create mode 100644 xen/arch/arm/Kconfig
 create mode 100644 xen/arch/arm/configs/arm32_defconfig
 create mode 100644 xen/arch/arm/configs/arm64_defconfig
 create mode 100644 xen/arch/x86/Kconfig
 create mode 100644 xen/arch/x86/configs/x86_64_defconfig
 create mode 100644 xen/common/Kconfig
 create mode 100644 xen/drivers/Kconfig
 create mode 100644 xen/scripts/kconfig/Makefile

diff --git a/.gitignore b/.gitignore
index 91e1430..780df23 100644
--- a/.gitignore
+++ b/.gitignore
@@ -217,6 +217,11 @@ tools/xentrace/tbctl
 tools/xentrace/xenctx
 tools/xentrace/xentrace
 xen/.banner
+xen/.config
+xen/.config.old
+xen/defconfig
+xen/**/*.cmd
+xen/**/modules.order
 xen/System.map
 xen/arch/arm/asm-offsets.s
 xen/arch/arm/xen.lds
@@ -239,6 +244,9 @@ xen/include/headers++.chk
 xen/include/asm
 xen/include/asm-*/asm-offsets.h
 xen/include/compat/*
+xen/include/config.h
+xen/include/config/
+xen/include/generated/
 xen/include/public/public
 xen/include/xen/*.new
 xen/include/xen/acm_policy.h
diff --git a/xen/Kconfig b/xen/Kconfig
new file mode 100644
index 000..b2d0fe2
--- /dev/null
+++ b/xen/Kconfig
@@ -0,0 +1,26 @@
+#
+# For a description of the syntax of this configuration file,
+# see Documentation/kbuild/kconfig-language.txt from the Linux
+# kernel source tree.
+#
+mainmenu "Xen/$SRCARCH $XEN_FULLVERSION Configuration"
+
+config SRCARCH
+   string
+   option env="SRCARCH"
+
+config ARCH
+   string
+   option env="ARCH"
+
+source "arch/$SRCARCH/Kconfig"
+
+config XEN_FULLVERSION
+   string
+   option env="XEN_FULLVERSION"
+
+config DEFCONFIG_LIST
+   string
+   option defconfig_list
+   default "$ARCH_DEFCONFIG"
+   default "arch/$SRCARCH/defconfig"
diff --git a/xen/Makefile b/xen/Makefile
index c556198..f2f4378 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -17,6 +17,9 @@ export XEN_ROOT := $(BASEDIR)/..
 
 EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
 
+# Don't break if the build process wasn't called from the top level
+XEN_TARGET_ARCH ?= $(shell uname -m)
+
 .PHONY: default
 default: build
 
@@ -88,6 +91,7 @@ _clean: delete-unfresh-files
$(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
+   $(MAKE) -f scripts/kconfig/Makefile clean
rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
$(TARGET)-syms *~ core
rm -f include/asm-*/asm-offsets.h
rm -f .banner
@@ -216,3 +220,16 @@ FORCE:
 
 %/: FORCE
$(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o
+
+kconfig := silentoldconfig oldconfig config menuconfig defconfig \
+   nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig
+.PHONY: $(kconfig)
+$(kconfig):
+   $(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) 
$@
+
+$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd
+   $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
ARCH=$(XEN_TARGET_ARCH) silentoldconfig
+
+# Allow people to just run `make` as before and not force them to configure
+$(BASEDIR)/.config $(BASEDIR)/include/config/auto.conf.cmd: ;
+   $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
ARCH=$(XEN_TARGET_ARCH) defconfig
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
new file mode 100644
index 000..a473137
--- /dev/null
+++ b/xen/arch/arm/Kconfig
@@ -0,0 +1,31 @@
+# Select 32 or 64 bit
+config 64BIT
+   bool "64-bit Xen" if ARCH = "arm64"
+   default ARCH != "arm32"
+   help
+ Say yes to build a 64-bit Xen
+ Say no to build a 32-bit Xen
+
+config ARM_32
+   def_bool y
+   depends on !64BIT
+
+config ARM_64
+   def_bool y
+