[OE-core] [PATCH] classes/kernel-yocto: Apply patches from BSP

Joshua Watt jpewhacker at gmail.com
Thu Dec 19 21:53:34 UTC 2019


On 12/19/19 3:18 PM, Bruce Ashfield wrote:
> On Thu, Dec 19, 2019 at 3:32 PM Joshua Watt <jpewhacker at gmail.com> wrote:
>> On Thu, Dec 19, 2019 at 1:30 PM Bruce Ashfield <bruce.ashfield at gmail.com> wrote:
>>> On Thu, Dec 19, 2019 at 1:53 PM Joshua Watt <jpewhacker at gmail.com> wrote:
>>>>
>>>> On 12/19/19 12:45 PM, Bruce Ashfield wrote:
>>>>> On Thu, Dec 19, 2019 at 1:38 PM Joshua Watt <jpewhacker at gmail.com> wrote:
>>>>>> 0f698dfd1c8 ("kernel-yocto: streamline patch, configuration and audit
>>>>>> phases") appears to have inadvertently broken support for BSP .scc files
>>>>>> to provide patches for the kernel. Restore this behavior by adding
>>>>>> $bsp_definition to the list of files processed for patches.
>>>>>> Additionally, the logic can be simplified now that the same elements are
>>>>>> used for both configuration fragments and patches
>>>>> Unfortunately no, we can't do this.
>>>>>
>>>>> It would reapply all the patches that are already integrated into the
>>>>> tree, and that distinction is the key part of that change.
>>>>>
>>>>> What exactly are you trying to do ? Define a userspace BSP ? If so,
>>>>> there are examples of this and I can dig them up and send them along.
>>>> We have a lot of boards running different SoCs (each with a different
>>>> vendor provided kernel) and we are trying to keep our sanity managing
>>>> all of the by using a metadata repo. So for example, we have a recipe
>>>> that pulls in vendor A's kernel directly from the upstream source, then
>>>> our local metadata repo which provides the scc files we need to
>>>> configure that repo. Inevitably, we end up needing to patch these
>>>> kernels, so I was hoping that we could provide the patches in the
>>>> metadata repo and add them to the BSP .scc file, but that wasn't working.
>>>>
>>> Right! It does make sense to keep the configs and patches together in
>>> that meta data repo.
>>>
>>> So you have your own kmeta repo, and that's where the BSP definitions
>>> that are being searched and found. Are those definitions completely
>>> standalone, or are they including some of the common yocto ktype
>>> definitions ? (It makes a difference to how they can be included).
>> I think they are standalone (e.g. they don't include any of the ktype files).
>>
>>
>>> I explained the details of the behaviour in an email on Oct 9th, with
>>> the title: "[yocto] Kernel patches pulled from BSP definition file are
>>> not applied.", so I won't repeat that long description here .. except
>>> to say that it is working as intended (but that doesn't mean it is set
>>> in stone .. see below ..). And yes, there are doc updates that need to
>>> happen for this to more clearly explain the design and options.
>>>
>>> That being said, there are a couple of things that can be done, and
>>> one that works right now:
>>>
>>> - The BSP definition SCC needs to be on the SRC_URI itself (as I
>>> describe in that other email), if your kernel recipe's have different
>>> names, that's doable. If they are under a common recipe, that of
>>> course would be harder (but you could use a variable for the MACHINE
>>> and have it work that way).
>> Does that mean the BSP scc files need to be moved from our metadata
>> repo to live alongside the recipe, or is there some special sauce that
>> allows the scc to be specified in SRC_URI, but pulled from our kmeta
>> repo?
> At the moment, yes.  Since you need to specify it in SRC_URI where the
> fetcher can find it (obviously :D), which implies that it isn't in
> that separate kernel meta repository.
>
> What, if anything, do you currently have on your SRC_URI ? Just the
> kernel repo and your kernel meta data repo ?

Yes, that is all we have.

>
> Let me see if I can come up with a simple way (probably patch) to avoid that.

That would be great! Thanks.

>
> Bruce
>
>>> That's the one that works now.
>>>
>>> A second option would be if I inject some logic to differentiate an
>>> integrated BSP versus one that requires patching. That's a slippery
>>> slope back into the complex logic that used to be in place, but I can
>>> think of a few viable ways to do it.
>>>
>>> Definitely a use case we can support, it'll just take some tweaking.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>
>>> Bruce
>>>
>>>
>>>
>>>
>>>
>>>>> Bruce
>>>>>
>>>>>> Signed-off-by: Joshua Watt <JPEWhacker at gmail.com>
>>>>>> ---
>>>>>>    meta/classes/kernel-yocto.bbclass | 7 ++-----
>>>>>>    1 file changed, 2 insertions(+), 5 deletions(-)
>>>>>>
>>>>>> diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
>>>>>> index ed9bcfa57c..08c02a8f50 100644
>>>>>> --- a/meta/classes/kernel-yocto.bbclass
>>>>>> +++ b/meta/classes/kernel-yocto.bbclass
>>>>>> @@ -193,12 +193,9 @@ do_kernel_metadata() {
>>>>>>                   if [ $? -ne 0 ]; then
>>>>>>                           bbfatal_log "Could not generate configuration queue for ${KMACHINE}."
>>>>>>                   fi
>>>>>> -       fi
>>>>>>
>>>>>> -       # run2: only generate patches for elements that have been passed on the SRC_URI
>>>>>> -       elements="`echo -n ${sccs} ${patches} ${KERNEL_FEATURES}`"
>>>>>> -       if [ -n "${elements}" ]; then
>>>>>> -               scc --force -o ${S}/${meta_dir}:patch --cmds patch ${includes} ${sccs} ${patches} ${KERNEL_FEATURES}
>>>>>> +               # run2: generate patches
>>>>>> +               scc --force -o ${S}/${meta_dir}:patch --cmds patch ${includes} ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}
>>>>>>                   if [ $? -ne 0 ]; then
>>>>>>                           bbfatal_log "Could not generate configuration queue for ${KMACHINE}."
>>>>>>                   fi
>>>>>> --
>>>>>> 2.23.0
>>>>>>
>>>>>> --
>>>>>> _______________________________________________
>>>>>> 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
>>> - "Use the force Harry" - Gandalf, Star Trek II
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II


More information about the Openembedded-core mailing list