| Message ID | 1366200612-22469-1-git-send-email-sergey_matyukevich@mentor.com |
|---|---|
| State | New |
| Headers | show |
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'
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"
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
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"
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
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(-)