4993 2013-08-07 17:37:12 +0000 Kernel module package naming 2013-09-30 18:02:44 +0000 1 1 7 Build System, Metadata & Runtime OE-Core kernel 1.4 x86 Multiple RESOLVED FIXED Medium normal 1.5 M4 1 yang.shi mark.hatle bluelightning bruce.ashfield mark.hatle tom.zanussi yang.shi --- --- No (bug/feature does not impact docs) oldest_to_newest 35468 0 yang.shi 2013-08-07 17:37:12 +0000 I'm building hello-mod package to run my multilib test. During my test, I found module-split generates kernel-module-hello package (naming style is "kernel-module-" + ${moudle_name}). And, the real kernel module file is included in this package. So, is this the right or expected behavior to have kernel module package named with module name (kernel-module-hello) rather than the package name (kernel-module-hello-mod)? Isn't the multilib name, and 'regular' name for a kernel module package supposed to be identical? In this case, when building hello-mod package, there will be two packages generated: kernel-module-hello-0.1-r0.4.intel_xeon_core.rpm hello-mod-0.1-r0.4.intel_xeon_core.rpm The real .ko file is in the first package, the second on is actually empty. And, when run multilib build, like lib32, multilib build will skip kernel-module-hello-0.1-r0.4.intel_xeon_core.rpm, but still need lib32-hello-mod. The workaround is to rename hello-mod to kernel-module-hello-mod. But, it sounds this package should be generated by default rather than kernel-module-hello. The kernel module package naming problem is caused by commit: commit 51928b6b5ca0a46a9dcd754483a19af58b95fa18 Author: Martin Jansa <martin.jansa@gmail.com> Date: Sat Mar 2 18:06:56 2013 +0100 kernel: extract functions for kernel modules to separate bbclass * this way we can reuse the same functionality also for external modules including module_autoload_foo and module_conf_foo functionality * MODULE_PACKAGES variable was removed (splited modules are now returned by do_split_packages * KERNEL_MODULES_META_PACKAGE is used to append all splitted packages to RDEPENDS. In kernel.bbclass it's old "kernel-modules" in module.bbclass it defaults to ${PN} for upgrade path from single PN with all modules to PN depending on all new kernel-module-* Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 35498 1 bluelightning 2013-08-08 15:55:39 +0000 Producing split module packages named kernel-module-* and another package which depends upon all of the split kernel modules is correct, that's what the patch you link to is intended to do. However, I do wonder which branch you are building because Mark added a workaround for the multilib package renaming recently: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=71aafc214fe407b7620e747c11dfb8326c867b1c Ideally this is something that would be handled automatically rather than having to be done within each external module recipe though. I'm also a little bit puzzled as to why there still seems to be a reference within the system to lib32-hello-mod which to my mind shouldn't really exist. 35500 2 yang.shi 2013-08-08 16:48:06 +0000 Thanks Paul. I'm trying to get a common fix based on Mark's workaround. I can workaround this by moving Mark's fix to module.bbclass. When I ran the test, I found there are two packages name start with "kernel-module-", i.e. kernel-module-hello-0.1-r0.4.intel_xeon_core.rpm kernel-module-hello-mod-0.1-r0.4.intel_xeon_core.rpm The first one is generated by module-split, the second one is generated by that workaround. So, even though there is kernel-module-hello-0.1-r0.4.intel_xeon_core.rpm, but multilib build is still seeking "lib32-hello-mod" without that workaround. By the implementation of multilib, kernel-module-hello-0.1-r0.4.intel_xeon_core.rpm is not enough to make multilib build happy, "kernel-module-" + ${PN} is still needed. If this is not a bug, then that workaround should be considered as a fix. 35511 3 bluelightning 2013-08-08 17:25:55 +0000 I think Mark's workaround is really just a workaround. If we want a proper fix for this then I would have thought the best option would be to have a way of excluding packages such as "hello-mod" explicitly from multilib processing. I'm not quite sure how that will work but I'm looking into it. 35513 4 yang.shi 2013-08-08 17:50:53 +0000 We can move Mark's workaround to higher level bbclass, like module.bbclass since every out-of-tree module packages inherits module.bbclass. It will make the renaming (hello-mod to kernel-module-hello-mod) automatically. Or we should create a new or look for an existing flag to make multilib build skip those packages with that flag. 35515 5 yang.shi 2013-08-08 18:04:24 +0000 Actually, in current implementation of module.bblcass and module-split, when you build hello-mod, you will get: kernel-module-hello.rpm (includes the .ko file, generated by module-split) hello-mod.rpm (the empty package, generated by module.bbclass) So, if we add PKG_${PN} = "kernel-module-${PN}" into module.bbclass, it will rename hello-mod.rpm (or any out-of-tree module package which inherits module.bbclass) to kernel-module-hello-mod to make multilib build happy. 35516 6 bluelightning 2013-08-08 18:06:55 +0000 I think that will cause problems if ${PN} happens to collide with the name of a module that is produced (which is not unlikely). 35518 7 yang.shi 2013-08-08 18:55:08 +0000 Yes, the "kernel-module-" package which has the real .ko file will be overwritten by "kernel-modue-" + ${PN} 35520 8 yang.shi 2013-08-08 19:07:35 +0000 Or we can rename it to "kernel-module-meta-" + {PN}, there won't be conflict when the package has the same name with the module. And, this also can make multilib build happy. I works, but may not be perfect. Does anyone care about the name of that rpm which is empty actually? 35546 9 bluelightning 2013-08-09 14:16:31 +0000 Using kernel-module-meta-${PN} seems a reasonable workaround to me. 35561 10 mark.hatle 2013-08-09 22:44:50 +0000 I've figured out what is happening. The package remapping code between the multilib bbclass and what occurs in the image.bbclass are happening at different times (or not at all). What is happening, when calling lib32-image (assuming 'c' in the module) image.bbclass: runtime_mapping PACKAGE_INSTALL = a b c multilib.bbclass: multilib rename PACKAGE_INSTALL = lib32-a lib32-b lib32-c What we want is: multilib.bbclass: multilib rename PACKAGE_INSTALL = lib32-a lib32-b lib32-c image.bbclass: runtime_mapping PACKAGE_INSTALL = lib32-a lib32-b c 36995 11 bluelightning 2013-09-19 15:47:07 +0000 Has this issue now been addressed? The patches have been merged to master at least: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=0bc564af07c1bae8112f834a60aea3b72af7de13 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=0e78c2931397f5a6811119ad33c9f95975aef8b7 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=8b075050e4889e0a06d6d7d01b28b8645d2f2af5 37369 12 bluelightning 2013-09-30 18:02:44 +0000 Marking this one resolved as per above.