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

List:       openembedded-core
Subject:    Re: [OE-core] [v2][PATCH 2/3] kernel.bbclass: link in kernel-features
From:       "Bruce Ashfield" <bruce.ashfield () gmail ! com>
Date:       2021-05-31 19:01:09
Message-ID: CADkTA4N0=kA61UUB05_mvtK2LHWi6jj=9KiKCnD6JTXaAktkDQ () mail ! gmail ! com
[Download RAW message or body]

On Mon, May 31, 2021 at 2:41 PM akuster808 <akuster808@gmail.com> wrote:
>
>
>
> On 5/31/21 11:20 AM, Bruce Ashfield wrote:
> > Thanks for v2!
> >
> > On Mon, May 31, 2021 at 2:16 PM Armin Kuster <akuster808@gmail.com> wrote:
> >> Signed-off-by: Armin Kuster <akuster808@gmail.com>
> >>
> >> --
> >> V2]
> >> rename kernel-kfrag to kernel-features
> >> ---
> >>  meta/classes/kernel.bbclass | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> >> index 8693ab86be..493136dfb0 100644
> >> --- a/meta/classes/kernel.bbclass
> >> +++ b/meta/classes/kernel.bbclass
> >> @@ -1,4 +1,4 @@
> >> -inherit linux-kernel-base kernel-module-split
> >> +inherit linux-kernel-base kernel-module-split kernel-features
> > Since we have the bbwarn, can this just go into kernel-yocto.bbclass
> > as a default include (for now) ?
> sure.
> >
> > As part of my series to move things around, I can relocate it to kernel.bbclass.
> >
> > We are sending two different messages as it stands, and everyone is
> > going to get a bbawarn that isn't using linux-yocto, but is using
> > kernel.bbclass :D (not that i mind, but others will object ;))
> Well. One message is from the Crazy Uncle ( and its not you )
>
> I am not hung up on my solution. Whatevery works  when I  define a
> 'unique name'  to pull in kernel fragment that live in the
> yocto-kernel-cache. I think is silly I am doing this in a s/w layer.

I'm doing similar things in my layers as well, since from some points
of view it is better to keep the userspace components that need those
features close to where the KERNEL_FEATURE is enabled. But having a
place where it is easy to look at what is available via
DISTRO_FEATURES -> KERNEL_FEATURES is a good idea, and that's what I
see in your solution.

But for this comment, I'm just suggesting that until we have some
other features in place, it can serve the same purpose, but be limited
in scope to kernel-yocto, where we know that it will work (and there's
a smaller set of kernel versions).

The other concern that I had with some of my earlier implementations,
is that with the _append technique, it isn't easy for a layer to
opt-out of having those fragments applied. They can of course provide
their own fragments, but keeping them out of KERNEL_FEATURES at all,
is harder. Which led me to think that there should also be a global
toggle.

Let me dig up my bugzilla and and see if there's any elements of that
we can apply to this.

Bruce

>
> -armin
> >
> > Bruce
> >
> >
> >>  COMPATIBLE_HOST = ".*-linux"
> >>
> >> --
> >> 2.25.1
> >>
> >>
> >> 
> >>
> >
>

--
- 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 (#152480): https://lists.openembedded.org/g/openembedded-core/message/152480
Mute This Topic: https://lists.openembedded.org/mt/83215858/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]