[OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built

Peter Kjellerstedt peter.kjellerstedt at axis.com
Mon Aug 21 15:16:06 UTC 2017


Just in case you missed it (as you didn’t comment on my comment about it), there was a typo in the log message as well.

//Peter

From: Bruce Ashfield [mailto:bruce.ashfield at gmail.com]
Sent: den 21 augusti 2017 17:14
To: Peter Kjellerstedt <peter.kjellerstedt at axis.com>
Cc: richard.purdie at linuxfoundation.org; openembedded-core at lists.openembedded.org
Subject: Re: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built



On Mon, Aug 21, 2017 at 11:03 AM, Bruce Ashfield <bruce.ashfield at gmail.com<mailto:bruce.ashfield at gmail.com>> wrote:


On Mon, Aug 21, 2017 at 11:00 AM, Peter Kjellerstedt <peter.kjellerstedt at axis.com<mailto:peter.kjellerstedt at axis.com>> wrote:
> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org<mailto:openembedded-core-bounces at lists.openembedded.org>
> [mailto:openembedded-core-bounces at lists.openembedded.org<mailto:openembedded-core-bounces at lists.openembedded.org>] On Behalf Of
> Bruce Ashfield
> Sent: den 21 augusti 2017 04:58
> To: richard.purdie at linuxfoundation.org<mailto:richard.purdie at linuxfoundation.org>
> Cc: openembedded-core at lists.openembedded.org<mailto:openembedded-core at lists.openembedded.org>
> Subject: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid
> BSPs are built
>
> There was a bug in the search routines responsible for locating
> BSP definitions which returned a valid match if only the ktype
> matched.
>
> This meant that someone looking for "qemux86foo" (which is an
> invalid definition) would potentially end up building "qemuarm"
> and be none the wiser (until it didn't boot).
>
> With this fix to the tools search routine, and improved return
> code testing, we will now stop the build and report and error to
> the user.
>
> [YOCTO: #11878]
>
> Signed-off-by: Bruce Ashfield <bruce.ashfield at windriver.com<mailto:bruce.ashfield at windriver.com>>
> ---
>  meta/classes/kernel-yocto.bbclass                       | 3 +++
>  meta/recipes-kernel/kern-tools/kern-tools-native_git.bb<http://kern-tools-native_git.bb> | 2 +-
>  2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/kernel-yocto.bb<http://kernel-yocto.bb>class b/meta/classes/kernel-yocto.bb<http://kernel-yocto.bb>class
> index 1ca0756c4959..3c6df92131bc 100644
> --- a/meta/classes/kernel-yocto.bb<http://kernel-yocto.bb>class
> +++ b/meta/classes/kernel-yocto.bb<http://kernel-yocto.bb>class
> @@ -143,6 +143,9 @@ do_kernel_metadata() {
>
>       # expand kernel features into their full path equivalents
>       bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE})
> +     if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
Use $bsp_definition instead of ${bsp_definition} since it is a
shell variable and not a bitbake variable.

I always use ${...}, so I'm going to stay consistent with what is already in
the file.


Actually, after looking at the code in that bbclass, I see this
used for a number of shell variables all over the place. This is
actually bad, and you should rewrite the code to not use ${variable}
for shell variables. The reason this is bad is because these
variables unnecessarily end up in the sstate hash for these functions,
and if someone actually happens to define a bitbake variable with the
same name as one of those shell variables, the result will not be what
is expected...

Not something high on my priority list. It's been that way since the beginning.

.. but I will loop back and take care of the issues before M4 closes. Just a bit busy
pushing out the new kernels and a slew of bug fixes.

This patch can be ignored (if needed) until I get back around to that.

Cheers,

Bruce


Cheers,

Bruce


> +             bbfatal_log "Could not locate BSP definiton for ${KMACHINE}/${LINUX_KERNEL_TYPE}."

Change "definiton" to "definition".

> +     fi
>       meta_dir=$(kgit --meta)
>
>       # run1: pull all the configuration fragments, no matter where they come from
> diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb<http://kern-tools-native_git.bb> b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb<http://kern-tools-native_git.bb>
> index 2217a31076a2..4a78b897d34f 100644
> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb<http://kern-tools-native_git.bb>
> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb<http://kern-tools-native_git.bb>
> @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b
>
>  DEPENDS = <file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b%0b%3e%0b%3e %20DEPENDS%20=%20> "git-native"
>
> -SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c"
> +SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83"
>  PR = "r12"
>  PV = "0.2+git${SRCPV}"
>
> --
> 2.5.0

//Peter

--
_______________________________________________
Openembedded-core mailing list
Openembedded-core at lists.openembedded.org<mailto:Openembedded-core at lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-core



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



--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170821/178c5b03/attachment-0002.html>


More information about the Openembedded-core mailing list