On Sun, May 30, 2021 at 4:54 PM akuster808 <[email protected]> wrote:
>
>
>
> On 5/30/21 1:47 PM, Bruce Ashfield wrote:
> > On Sun, May 30, 2021 at 2:06 PM Armin Kuster <[email protected]> wrote:
> >> This provides a common place to define kernel fragments
> >> that may be usefull to the larger community.
> > Not a bad idea at all, but what about calling the class
> > "kernel-features", versus kfrag ? That describes the purpose, versus
> > what the mechanism does.
> works for me.
> >
> > A 2nd suggestion would be to bbwarn if this is inherited, but
> > kernel-yocto is not.
> seems reasonable.  I did wonder the best place to place for thie. The
> kernel cache can be used w/o linux-yocto.

True that it can be, but we don't have a universal way to detect
fragment merging ... and as we all know, the implementations are all
over the place.

I'd suggest that as a starting point, check for kernel-yocto, and we
could enhance the check in the future if there are other kernel
recipes that are doing merging, that also want to use this.

There's lots of other checks that we could do about
kernel/machine/version combinations, etc (and in fact, i have an old
bugzilla for them somewhere), but I'd stick with simple first .. and
then we can see what makes sense to incrementally add.

> >
> > Note: as mentioned during the yocto summit, I do have patches that
> > make fragments more universally available, when I get them ready, we
> > could remove the bbwarn.
> Would those patches eliminate the need for a class like this?
>

Nope. They just drive the fragment operations into kernel.bbclass and
only enable it when a .cfg/.scc are detected in the SRC_URI (so as to
not impact class/standard kernel recipes). This is just delivering a
fragment to that operation, so the class would still do the same job.

Bruce

> -armin
> >
> > Bruce
> >
> >> Signed-off-by: Armin Kuster <[email protected]>
> >> ---
> >>  meta/classes/kernel-kfrag.bbclass | 8 ++++++++
> >>  1 file changed, 8 insertions(+)
> >>  create mode 100644 meta/classes/kernel-kfrag.bbclass
> >>
> >> diff --git a/meta/classes/kernel-kfrag.bbclass 
> >> b/meta/classes/kernel-kfrag.bbclass
> >> new file mode 100644
> >> index 00000000000..c0c5667b519
> >> --- /dev/null
> >> +++ b/meta/classes/kernel-kfrag.bbclass
> >> @@ -0,0 +1,8 @@
> >> +#
> >> +# Class to place yocto-kernel-cache fragments
> >> +# selections usfull to anyone
> >> +#
> >> +
> >> +KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", 
> >> "apparmor", " features/apparmor/apparmor.scc", "" ,d)}"
> >> +KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", 
> >> "smack", " features/smack/smack.scc", "" ,d)}"
> >> +KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", 
> >> "dm-verity", " features/device-mapper/dm-verity.scc", "" ,d)}"
> >> --
> >> 2.24.3
> >>
> >>
> >> 
> >>
> >
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152456): 
https://lists.openembedded.org/g/openembedded-core/message/152456
Mute This Topic: https://lists.openembedded.org/mt/83193446/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to