[OE-core] [PATCH] classes/kernel-yocto: Apply patches from BSP
Bruce Ashfield
bruce.ashfield at gmail.com
Thu Dec 19 22:14:46 UTC 2019
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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-kernel-yocto-allow-external-aka-non-integrated-BSPs-.patch
Type: application/octet-stream
Size: 2535 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20191219/d05952dd/attachment-0001.obj>
More information about the Openembedded-core
mailing list