[poky] [PATCH 1/2] module: build and clean hostprogs for each module

[Gary Thomas]

On 03/03/2011 09:39 PM, Darren Hart wrote:
> On 03/03/2011 08:59 AM, Gary Thomas wrote:
>> On 03/03/2011 09:50 AM, Gary Thomas wrote:
>>> On 03/02/2011 11:00 AM, Darren Hart wrote:
>>>> From: Darren Hart<dvhart at linux.intel.com>
>>>>
>>>> This fixes [BUGID #241]
>>>>
>>>> The kernel hostprogs are built for the host architecture. They should
>>>> not
>>>> be deployed with to the target, and they should not be included in an
>>>> sstate
>>>> package which might get reused on a host of a different architecture.
>>>>
>>>> As we don't build many out-of-tree modules, this patch takes the
>>>> approach
>>>> of building the hostprogs as part of the module compile process with a
>>>> do_compile_prepend() routine in module.bbclass. To ensure the hostprogs
>>>> don't contaminate the build, they are removed in do_install_append().
>>>>
>>>> Signed-off-by: Darren Hart<dvhart at linux.intel.com>
>>>> CC: Gary Thomas<gary at mlbassoc.com>
>>>
>>> Sadly, this doesn't seem to work for me. I don't see any indication in
>>> run.do_compile that the extra steps were added at all.
>>>
>>> Will it matter if my recipe overrides the do_compile() method?
>>>
>>
>> Also, when you tested this, what was your target MACHINE (in particular,
>> was the target a different architecture than the build host?) I ask because
>> I tried to just manually insert the compile_prepend() functions into my
>> recipe and it ended up trying to build host tools (that's what the fuss
>> is all about) using the target toolchain.
>
> I made some modifications to avoid a Race that RP pointed out (just removed the cleans from the module.bbclass since they weren't necessary anyway). With this, I set my MACHINE to
> beagleboard and built minimal. You can see from the following that hostprogs were build for the host and the module for the target:
>
> dvhart at rage:build-beagleboard$ file
> ./tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux-beagleboard-standard-build/scripts/basic/fixdep
>
> ./tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git1+e2737075b79e4fc682e41051cf1c0bc47a47d502_1+2b412826bbeb4a16abe2ea74f2456ab880c6e3c1-r16/linux-beagleboard-standard-build/scripts/basic/fixdep:
> ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped

Why are you looking in ${KERNEL_SRC}?  It may not exist (think rm_work) when your module gets built.

The example recipe I have uses ${STAGING_KERNEL_DIR} something like this:
   make -C ${STAGING_KERNEL_DIR} M=src

Also, if you look at the run.do_compile script for your module recipe, is
there any indication that the compile_prepend() stuff was even added?  I
don't see it in mine (yes, it inherits module)

>
> dvhart at rage:build-beagleboard$ file ./tmp/work/beagleboard-poky-linux-gnueabi/hello-world-mod-1.0-r0/package/lib/modules/2.6.37.2-yocto-standard+/extra/hello_world.ko
> ./tmp/work/beagleboard-poky-linux-gnueabi/hello-world-mod-1.0-r0/package/lib/modules/2.6.37.2-yocto-standard+/extra/hello_world.ko: ELF 32-bit LSB relocatable, ARM, version 1
> (SYSV), not stripped
>
> I'm going to do a beagleboard boot test, but if that works I'll be resending these changes to close BUG 241 as they work on both qemux86 and beagleboard using hello-world-mod which
> uses a very typical out-of-tree kernel module Make setup.
>

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------