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

Joshua Watt jpewhacker at gmail.com
Fri Dec 20 15:07:43 UTC 2019 

On Thu, Dec 19, 2019 at 4:14 PM Bruce Ashfield <bruce.ashfield at gmail.com> wrote:
>
> On Thu, Dec 19, 2019 at 4:53 PM Joshua Watt <jpewhacker at gmail.com> wrote:
> >
> >
> > 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.
> >
>
> Attached is my proposed solution. Hopefully the commit log is detailed
> enough to explain what I'm trying to do :D
>
> I've only tested that it doesn't break a standard BSP build, so let me
> know if this solves your use case, and I'll run some additional tests
> and send it to the list.

I had to make one minor fix to your patch (the assignment of the sccs
variable needs the spaces around the "=" removed to be valid shell
code), but other than that your patch works great for me and does
exactly what I want.

Thanks!

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