Out-of-tree kernel module in multilib build

[Yang Shi <yang.shi@windriver.com>]

Hi folks,

I'm looking a defect about out-of-tree kernel module in multilib build.

I'm building hello-mod package to run my 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 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?


But, for making multilib build happy, we need kernel-module-hello-mod 
package (naming style is "kernel-module-${PN}). Actually, it's a empty 
package (hello-mod or kernel-module-hello-mod). So, in hello-mod case, 
we need both:

kernel-module-hello-0.1-r0.4.intel_xeon_core.rpm
kernel-module-hello-mod-0.1-r0.4.intel_xeon_core.rpm

As we known, the workaround is to rename the package name to 
"kernel-module-" + ${PN} in hello-mod bb file otherwise multilib needs 
${mlib}-hello-mod package, i.e. lib32-hello-mod.

I'm not quite sure if this is a real fix or just a workaround? If it's 
not a real fix, how can we make multilib skip out-of-tree kernel module 
package? What code should I look into?

How are in-tree kernel modules skipped by multilib? Just because their 
names start with "kernel-module-"?

If we can't suppose multilib name, and 'regular' name for a kernel 
module package are identical, the workaround may sound like a real fix.

Thanks,
Yang