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

[Bruce Ashfield]

On Mon, Aug 21, 2017 at 11:16 AM, Peter Kjellerstedt <
peter.kjellerstedt at axis.com> wrote:

> 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.
>

Yup. Noticed that, it isn't the only typo ;)

This is a resend of a patch I sent a few weeks ago, so I'm not too worried
if it sits or not.

Cheers,

Bruce


>
>
> //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>
> wrote:
>
>
>
>
>
> On Mon, Aug 21, 2017 at 11:00 AM, Peter Kjellerstedt <
> peter.kjellerstedt at axis.com> wrote:
>
> > -----Original Message-----
> > From: 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
> > Cc: 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>
> > ---
> >  meta/classes/kernel-yocto.bbclass                       | 3 +++
> >  meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
> >  2 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/
> kernel-yocto.bbclass
> > index 1ca0756c4959..3c6df92131bc 100644
> > --- a/meta/classes/kernel-yocto.bbclass
> > +++ b/meta/classes/kernel-yocto.bbclass
> > @@ -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
> b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> > index 2217a31076a2..4a78b897d34f 100644
> > --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> > +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> > @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;
> beginline=5;endline=9;md5=a6c2fa8aef1b
> >
> >  DEPENDS = "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
> 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"
>



-- 
"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/ae92af74/attachment-0002.html>