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>
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.
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.
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.
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.
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.
I think that will cause problems if ${PN} happens to collide with the name of a module that is produced (which is not unlikely).
Yes, the "kernel-module-" package which has the real .ko file will be overwritten by "kernel-modue-" + ${PN}
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?
Using kernel-module-meta-${PN} seems a reasonable workaround to me.
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
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
Marking this one resolved as per above.