Hello Bruce,
thanks for looking into this!
On Fri, 2023-11-03 at 09:00 -0400, Bruce Ashfield wrote:
> > > I cannot easily point you to something publicly available... But roughly
> > > it's a
> > > combination of meta-virtualization and a kernel recipe derived from
> > > kernel-yocto.bbclass.
> > >
> > > Now I long as one doesn't have any type=kmeta, meta-virtualization
> > > doesn't pull
> > > git://git.yoctoproject.org/yocto-kernel-cache and adding
> > > "file://features/debug;type=kmeta;destsuffix=features/debug" to SRC_URI
> > > causes
> > > yocto-kernel-cache to be pulled even though there is no logical reason
> > > for this.
> >
> > That's not what my local tests show. It is keying off an inherit of
> > kernel-yocto,
> > not kmeta, but even by extension, seeing that fragment merging is available
> > (whether keyed of kmeta or the inherit of kernel-yocto), that is the logic
> > as to
> > why it pulls it in (and the use of it is what I explained above).
>
> Cancel that comment, I do see it now. And yes, if there's any kmeta fragments
> in the SRC_URI that is used to construct the kernel include file name, which
> then double checks if kernel-yocto is inherited, and the combination of the
> two
> indicates that the fragments should be made available for the packages in the
> layer to be properly supported at runtime.
>
> There should be a way for you to manipulate the do_kernel_metadata[depends]
> value in your own bbappend to remove the dependency on the repo.
>
> I can also try and think up another variable or a way to exclude that
> dependency
> .. but again, it is an intended dependency, and I was trying for a lighter
> touch
> with the existing checks, and I don't want to make them too complex or
> introduce
> a bug where the fragments stop being pulled in where they have currently been
> pulled as a dependency.
This unfortunately means undoing the whole linux-yocto_virtualization.inc
with all appended KERNEL_MODULE_AUTOLOAD and KERNEL_FEATURES and turns to be
quite messy at the end.
So the logic of pulling the whole linux-yocto_virtualization.inc
if d.getVar('SRC_URI').find('type=kmeta')
is not so obvious... For those re-using type=kmeta for something else than
yocto-kernel-cache.
We tend to trust our kernel configs and want to know which modules we load...
For instance if we only do containers, we still might want meta-virtualization,
but not necessary KVM, right?
--
Alexander Sverdlin
Siemens AG
www.siemens.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8418):
https://lists.yoctoproject.org/g/meta-virtualization/message/8418
Mute This Topic: https://lists.yoctoproject.org/mt/102338788/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
