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

[Doug Goldstein <cardoe@xxxxxxxxxx>]

On 12/8/15 8:25 AM, Jan Beulich wrote:
>>>> On 08.12.15 at 15:16, <cardoe@xxxxxxxxxx> wrote:
>> On 12/8/15 1:32 AM, Jan Beulich wrote:
>>>>>> On 07.12.15 at 22:27, <cardoe@xxxxxxxxxx> wrote:
>>>> On 12/3/15 2:57 AM, Jan Beulich wrote:
>>>>>>>> On 03.12.15 at 01:34, <cardoe@xxxxxxxxxx> wrote:
>>>>>> On 12/1/15 5:22 AM, Jan Beulich wrote:
>>>>>>>>>> On 30.11.15 at 18:53, <cardoe@xxxxxxxxxx> wrote:
>>>>>>>> On 11/30/15 8:36 AM, Jan Beulich wrote:
>>>>>>>>>>>> On 24.11.15 at 18:51, <cardoe@xxxxxxxxxx> 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

Attachment: signature.asc
Description: OpenPGP digital signature

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