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

[Joshua Watt]

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?

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