Re: [PATCH] map_kernel_arch: x86 sub-architectures

[Sergey Matyukevich <Sergey_Matyukevich@mentor.com>]

On 04/17/2013 06:24 PM, Bruce Ashfield wrote:
> On Wed, Apr 17, 2013 at 10:05 AM, Sergey Matyukevich
> <Sergey_Matyukevich@mentor.com>  wrote:
>> Hello,
>>
>>
>>>> Suppose we build software for x86 targets on x86 build hosts. There are
>>>> use-cases
>>>> when it is not enough to specify x86 as a kernel architecture. It is
>>>> necessary
>>>
>>>
>>> What are the details of the use cases ? I've never run into this myself,
>>> and
>>> almost no parts of the kernel build infrastructure differentiates between
>>> x86 and x86_64 .. so I'm curious to know what is breaking.
>>
>>
>> So far we observed this problem in two cases:
>> - build systemtap modules for x86_32 target on x86_64 build hosts
>> - build virtualbox-guest modules for x86_32 target on x86_64 build hosts
>
> I'm still interested in drilling down on the details. If the build of
> those modules
> is being influenced by the build host vs the target kernel, that's a form of
> host contamination in my book.
>
> i.e. so with this change you are setting TARGET_ARCH more precisely, but
> that's going to impact the kernel build itself, and the current x86 is exactly
> what other layers and recipes would expect, as does the kernel build.
>
> With the more specific setting, clearly the builds of the modules you mention
> make use of it, is it that they are currently seeing 'x86' and defaulting to
> 64 bit ? I'd expect that they could be patched to look at the staged kernel
> source or the .config to determine something similar, and the change would
> be more isolated. I'm guessing, since as I said, I haven't run into these myself
> and haven't gone to crawl the code yet.
>
> Adding a return value of i386 now is also a interesting, it currently
> isn't returned,
> and doesn't really mean anything useful to the kernel build anymore.
> It's strictly
> compatibility. Why doesn't a return of 'x86' work in any case that you are
> returning i386 ?

Concerning your comments:

- host contamination
It doesn't seem to be a contamination by host settings. In the case of 
systemtap modules, build failed for ARCH=x86, but was ok for ARCH=i386. 
However note, that it was is not systemtap itself, it was a custom 
systemtap probe module built by systemtap tools.

- i386 vs x86
As you noted, i386 does not mean anything really useful anymore from the 
'kernel point of view'. Roughtly speaking, it is an alias for x86_32. 
That is why it should not break any other layers and recipes which 
expect x86. In other words, split i386-x86-x86_64 affects only those who 
are interested in this information.


Sure, all the mentioned issues could be fixed in an isolated way in 
their recipes. Though after I ran into the same type of issue twice, I 
thought it might be reasonable to propagate the fix upstairs, to oe-core.


Thanks,
Sergey