On Fri, Nov 3, 2023 at 9:14 AM Sverdlin, Alexander <[email protected]> wrote: > > 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.
In theory, I created the type=kmeta for just that purpose, kernel-cache and fragment extensions, so keying on it is at least consistent :) 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. Bruce > > 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 -- - 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 (#8419): https://lists.yoctoproject.org/g/meta-virtualization/message/8419 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]] -=-=-=-=-=-=-=-=-=-=-=-
