[oe] [PATCH 2/2] iscsitarget: skip the arch test for kernel modules

[Joe MacDonald]

Hi Jackie,

[Re: [oe] [PATCH 2/2] iscsitarget: skip the arch test for kernel modules] On 16.03.03 (Thu 04:41) Huang, Jie (Jackie) wrote:

> > On Wed, Nov 25, 2015 at 3:27 AM, <jackie.huang at windriver.com> wrote:
> > From: Jackie Huang <jackie.huang at windriver.com>
> > 
> > Kernel modules may not have the same architecture as user space.
> > So we tell INSANE_SKIP to skip checking the arch for the modules.
> > This is consistent with other kernel modules and the kernel recipe.
> > 
> > This one still hasn't been merged and since iscsitarget is currently unbuildable, 
> > I'm not in a rush to merge this one particularly since I'm not really clear on the 
> > logic underlying the change.  I searched the archives and found your response to 
> > Martin was essentially "see my netmap-modules patch for an explanation" and in that 
> > one the explanation was basically "this is the way other kernel modules do it". 
> 
> I think I meant to refer to this one which is not merged either:
> commit 6727154c929f3dc8ed86bab29aa1de88620906e9
> Author: Jackie Huang <jackie.huang at windriver.com>
> Date:   Tue Nov 17 01:44:47 2015 -0800
> 
>     netmap-modules: skip the arch check for kernel module
>     
>     When building on a multilib capable BSP, it's possible for the
>     kernel bit size to be different than the userspace. Avoid the
>     QA test when building the kernel module.
>     
>     Signed-off-by: Jackie Huang <jackie.huang at windriver.com>
> 
> sorry that if the explanation is not clear enough.
> 
> > I merged that one but now I'm thinking I shouldn't have without more
> > careful consideration.  
> 
> The one you merged is "netmap-modules: Modules may not have the same arch as userspace"
> and Mark helped to split and re-word the commit message like what it is now.

Okay, so at least I am looking at what I think I'm looking at.

> > Am I correct in thinking that this problem only shows up when you're
> > building for multilib?  
> 
> We have BSPs with a 64 bit kernel + modules + 32 bit userspace by default, the
> problem always show up when we're building such BSP, and we have a bbclass to
> add INSANE_SKIP for internal modules:
> 
> # sanity updates. The do_package_qa_prepend and vmlinux sanity
> # flags allow a 64 bit kernel + modules to be packaged against a
> # 32 bit userspace. If external modules are built, they must supply
> # their own INSANE_SKIP_<module> = "arch" if they want to be properly
> # packaged.
> python do_package_qa_prepend () {

I guess in this case you mean it's a bbclass that's internal to Wind
River, I did a quick search and couldn't find the code you reference above
anywhere in my poky tree.

> > I've reverted "netmap-modules: Modules may not have the same arch as userspace" in my contrib 
> > tree at http://git.openembedded.org/meta-openembedded-contrib/log/?h=joeythesaint/meta-networking-next 
> > and my initial test builds showed no QA issues related to netmap-modules and the arch checks.  
> > So I started looking around for other kernel modules doing something similar and I don't actually 
> > see this "INSANE_SKIP_kernel-module-*" construct being used anywhere else in meta-oe or poky 
> > (and at the least I would expect something like cryptodev-module to need it, it looks like an 
> > analogue to me).  Can you fill me in on what's special with iscsitarget and netmap, because 
> > even if it is a multilib issue, why wouldn't that be showing up for other kernel modules built 
> > in poky?
> 
> That's because there is no such BSP like I mentioned above in poky, I
> undersatand if this is not accpeted, we may add this in our own layer.

I think that's best, since otherwise the you'll be submitting these
changes for any external module to support a use-case that we don't have
in Yocto and there's no obvious corresponding behaviour in poky.

Thanks.

-- 
-Joe MacDonald.
:wq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20160303/ab40d729/attachment-0002.sig>