On Fri, Nov 3, 2023 at 10:21 AM Sverdlin, Alexander
<[email protected]> wrote:
>
> Hello Bruce,
>
> On Fri, 2023-11-03 at 09:59 -0400, Bruce Ashfield wrote:
> > In theory, I created the type=kmeta for just that purpose, kernel-cache and
> > fragment extensions, so keying on it is at least consistent :)
>
> I had this feeling regarding type=kmeta, trying to understand the limited
> documentation and how to use it with file:// and nested directories.
>
> However, I find it extremely useful to have custom .scc files with
> the whole verification machinery in kernel-yocto.bbclass.
>
> I doubt that each and every use case must be upstreamed and go
> via yocto-kernel-cache, I believe users may have valid but very
> specific .scc tailored for their use cases.

Right. I want to support your use case, and encourage the sharing of
useful fragments.  Definitely not a requirement to upstream everything.

But I did make the shared fragments a requirement for meta-virt with
the intention of deleting the local ones. That's why you see that
dependency kick in.

Having the concepts and tools used and being useful is a good first step
and I'm good with that, and like I said, I do want to support it.

>
> > > I can also try and think up another variable or a way to exclude that
> > > dependency
>
> So maybe another variable could be an answer.
> Because it's hard to distinguish real type-kmeta yocto-kernel-cache
> (especially if people would have their local, maybe partial mirrors)
> from just couple of .scc files.

Very likely this is the solution, have a way to opt-out. Knowing that
you can possibly run into issues with KERNEL_FEATURE validation
or with runtime if you do opt out. I'll probably emit a similar warning
to the one you get if you include meta-virt but don't enable the
virtualization distro feature.

Bruce

>
> > But I do agree that it is pulling in (potential) support for ALL of the 
> > features
> > in meta-virt. That's a balance between having too many fine grained
> > distro features, versus the one big switch "virtualization".
> >
> > It could be finer grained, let me see what I can come up with to slim things
> > down a bit .. but as it relates to the kernel-cache, even a more fine 
> > grained
> > trigger will want the kernel-cache for either virtualization,
> > containers, xen, etc.
> >
> > I'll follow up later today, once I've thought about this a bit more.
>
> --
> Alexander Sverdlin
> Siemens AG
> www.siemens.com



-- 
- 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 (#8421): 
https://lists.yoctoproject.org/g/meta-virtualization/message/8421
Mute This Topic: https://lists.yoctoproject.org/mt/102338788/21656
Group Owner: [email protected]
Unsubscribe: 
https://lists.yoctoproject.org/g/meta-virtualization/leave/6693005/21656/1014668956/xyzzy
 [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to