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

Bruce Ashfield
2017-08-23T14:42:44Z

On 08/23/2017 10:40 AM, Khem Raj wrote:
> On Wed, Aug 23, 2017 at 5:37 AM, Bruce Ashfield
> <bruce.ashfield@windriver.com> wrote:
>> On 08/22/2017 11:40 PM, Khem Raj wrote:
>>>
>>> On Sun, Aug 20, 2017 at 7:58 PM, Bruce Ashfield
>>> <bruce.ashfield@windriver.com> wrote:
>>>>
>>>> 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@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
>>>> + bbfatal_log "Could not locate BSP definiton for
>>>> ${KMACHINE}/${LINUX_KERNEL_TYPE}."
>>>> + fi
>>>
>>>
>>> this breaks non linux-yocto kernels which are using the kernel infra
>>> from OE-Core
>>> since they may not have kmeta structure and bsp_definition may be empty
>>> for them
>>> so either provide a way to override bsp_definition to something dummy or
>>> infact
>>> fall back to dummy by default with a warning or note during parse
>>> time. fatal is a bit harsh here.
>>
>>
>> Fair enough. I can make it a warning versus fatal, or only make it
>> fatal if I detect a defconfig.
>>
>> The issue is that the tools haven't found a configuration entry point
>> and could end up building a garbage/invalid configuration. A defconfig
>> could stand in as a 'valid entry' point, since it signifies a baseline
>> configuration.
>>
>> Also, I do have completed code to move fragment merging into a common
>> location and avoid things like this .. once it goes through some more
>> compatibility testing, I'll post it to the list.
>
>
> Irrespective this was merged today into master, can you send a followup
> quickly so we can unbreak meta-raspberrypi

I hadn't pulled today, and yes, I'll send something by end of day, since
I don't want this to stay broken!

Cheers,

Bruce

>
>>
>> Bruce
>>
>>
>>>
>>>> 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
>>>>
>>>> --
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>