From: Gary Thomas <gary@mlbassoc.com>
To: Darren Hart <dvhart@linux.intel.com>
Cc: poky@yoctoproject.org
Subject: Re: [PATCH 1/2] module: build and clean hostprogs for each module
Date: Fri, 04 Mar 2011 04:44:57 -0700 [thread overview]
Message-ID: <4D70D0B9.3020902@mlbassoc.com> (raw)
In-Reply-To: <4D706D10.4050809@linux.intel.com>
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@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@linux.intel.com>
>>>> CC: Gary Thomas<gary@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@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@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
------------------------------------------------------------
next prev parent reply other threads:[~2011-03-04 11:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-02 18:00 [PATCH 1/2] module: build and clean hostprogs for each module Darren Hart
2011-03-03 16:50 ` Gary Thomas
2011-03-03 16:59 ` Gary Thomas
2011-03-04 4:39 ` Darren Hart
2011-03-04 11:44 ` Gary Thomas [this message]
2011-03-04 20:33 ` Darren Hart
2011-03-04 21:31 ` Darren Hart
2011-03-06 16:21 ` Gary Thomas
2011-03-07 22:16 ` Darren Hart
2011-03-04 4:36 ` Darren Hart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D70D0B9.3020902@mlbassoc.com \
--to=gary@mlbassoc.com \
--cc=dvhart@linux.intel.com \
--cc=poky@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.