[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    Re: [OE-core] [PATCH 1/2] kernel-kfrag: add new class
From:       "Bruce Ashfield" <bruce.ashfield () gmail ! com>
Date:       2021-05-31 2:27:52
Message-ID: CADkTA4OWSw6DL5bJzoH3XVJfSpO+3=jZkTuCHnggND4RT-=PbQ () mail ! gmail ! com
[Download RAW message or body]

On Sun, May 30, 2021 at 4:54 PM akuster808 <akuster808@gmail.com> wrote:
> 
> 
> 
> On 5/30/21 1:47 PM, Bruce Ashfield wrote:
> > On Sun, May 30, 2021 at 2:06 PM Armin Kuster <akuster808@gmail.com> 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 <akuster808@gmail.com>
> > > ---
> > > 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/4454766
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [openembedded-core@marc.info]
-=-=-=-=-=-=-=-=-=-=-=-



[prev in list] [next in list] [prev in thread] [next in thread]