7591 2015-04-09 15:27:37 +0000 More reliable external kernel module selection 2015-10-21 19:25:26 +0000 1 1 7 Build System, Metadata & Runtime OE-Core kernel 1.8 x86 Multiple RESOLVED FIXED Medium enhancement 2.0 1 bluelightning california.l.sullivan bruce.ashfield tom.zanussi --- --- Yes (doc changes required) oldest_to_newest 50187 0 bluelightning 2015-04-09 15:27:37 +0000 If you have an out-of-tree kernel module recipe and simply add kernel-module-xyz to MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS in the machine config, the module may not actually appear in the image - the reason being that the kernel recipe itself claims via PACKAGES_DYNAMIC that it provides kernel-module-.* and thus the dependency is satisfied as far as bitbake is concerned, and since it is a RRECOMMENDS it doesn't matter that it isn't satisfied at runtime. The workaround is to explicitly name the external kernel module recipe somewhere (or the main dummy package it builds) such that it is forced to build. It seems to me at minimum we need to document this in the kernel development manual. Another option would be to document that the user should explicitly add the package names to PACKAGES in their module recipe, which bitbake will take in preference to PACKAGES_DYNAMIC from the kernel - though someone would need to verify that this actually works. 52641 1 california.l.sullivan 2015-07-27 22:04:35 +0000 I did some testing on the other option. It seems to work. With no changes to any other recipes, adding MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS = "kernel-module-hello" to the machine conf (with "hello" being the module that hello-mod in yocto-skeleton creates), there was no error reported and the module was not put in the image. After adding PACKAGES = "kernel-module-hello" to the hello-mod_0.1.bb recipe and rebuilding, the module "hello" was added to the image. 55586 2 california.l.sullivan 2015-10-21 19:25:26 +0000 Documentation updated; see commit 2c51eae23b634cdace5a119ee1a6c8e8ba76dc45 in the yocto-docs repo.