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

[Bruce Ashfield]

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

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