Patchwork map_kernel_arch: x86 sub-architectures

login
register
mail settings
Submitter Sergey Matyukevich
Date April 17, 2013, 12:10 p.m.
Message ID <1366200612-22469-1-git-send-email-sergey_matyukevich@mentor.com>
Download mbox | patch
Permalink /patch/48427/
State New
Headers show

Comments

Sergey Matyukevich - April 17, 2013, 12:10 p.m.
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
to go one step further and to specify proper x86 sub-architecture (i386 or
x86_64) of the target system.

This patch modifies kernel-arch.bbclass in the following way:
 - adds x86_64 to the list of valid architectures
 - differentiates between i386 and x86_64 sub-architectures in map_kernel_arch

Signed-off-by: Sergey Matyukevich <sergey_matyukevich@mentor.com>
---
 meta/classes/kernel-arch.bbclass |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)
Bruce Ashfield - April 17, 2013, 1:52 p.m.
On Wed, Apr 17, 2013 at 8:10 AM, Sergey Matyukevich
<sergey_matyukevich@mentor.com> wrote:
> 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.

Bruce

> to go one step further and to specify proper x86 sub-architecture (i386 or
> x86_64) of the target system.
>
> This patch modifies kernel-arch.bbclass in the following way:
>  - adds x86_64 to the list of valid architectures
>  - differentiates between i386 and x86_64 sub-architectures in map_kernel_arch
>
> Signed-off-by: Sergey Matyukevich <sergey_matyukevich@mentor.com>
> ---
>  meta/classes/kernel-arch.bbclass |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
> index b3b71ba..3e29f45 100644
> --- a/meta/classes/kernel-arch.bbclass
> +++ b/meta/classes/kernel-arch.bbclass
> @@ -5,7 +5,7 @@
>  #
>
>  valid_archs = "alpha cris ia64 \
> -               i386 x86 \
> +               i386 x86 x86_64 \
>                 m68knommu m68k ppc powerpc powerpc64 ppc64  \
>                 sparc sparc64 \
>                 arm aarch64 \
> @@ -20,7 +20,9 @@ def map_kernel_arch(a, d):
>
>      valid_archs = d.getVar('valid_archs', True).split()
>
> -    if   re.match('(i.86|athlon|x86.64)$', a):  return 'x86'
> +    if   re.match('athlon$', a):                return 'x86'
> +    elif re.match('i.86$', a):                  return 'i386'
> +    elif re.match('x86.64$', a):                return 'x86_64'
>      elif re.match('armeb$', a):                 return 'arm'
>      elif re.match('aarch64$', a):               return 'arm64'
>      elif re.match('mips(el|64|64el)$', a):      return 'mips'
> --
> 1.7.2.5
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
Sergey Matyukevich - April 17, 2013, 2:05 p.m.
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

Sergey
Bruce Ashfield - April 17, 2013, 2:24 p.m.
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 ?

Cheers,

Bruce

>
> Sergey



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
Sergey Matyukevich - April 18, 2013, 12:34 p.m.
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

Patch

diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
index b3b71ba..3e29f45 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -5,7 +5,7 @@ 
 #
 
 valid_archs = "alpha cris ia64 \
-               i386 x86 \
+               i386 x86 x86_64 \
                m68knommu m68k ppc powerpc powerpc64 ppc64  \
                sparc sparc64 \
                arm aarch64 \
@@ -20,7 +20,9 @@  def map_kernel_arch(a, d):
 
     valid_archs = d.getVar('valid_archs', True).split()
 
-    if   re.match('(i.86|athlon|x86.64)$', a):  return 'x86'
+    if   re.match('athlon$', a):                return 'x86'
+    elif re.match('i.86$', a):                  return 'i386'
+    elif re.match('x86.64$', a):                return 'x86_64'
     elif re.match('armeb$', a):                 return 'arm'
     elif re.match('aarch64$', a):               return 'arm64'
     elif re.match('mips(el|64|64el)$', a):      return 'mips'