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

[Bruce Ashfield <bruce.ashfield@windriver.com>]

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.

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