[OE-core] [PATCH] map_kernel_arch: x86 sub-architectures

[Bruce Ashfield]

On Wed, Apr 17, 2013 at 10:05 AM, Sergey Matyukevich
<Sergey_Matyukevich at 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 ?

Cheers,

Bruce

>
> Sergey



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"