From: Darren Hart <dvhart@linux.intel.com>
To: Bruce Ashfield <bruce.ashfield@windriver.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>,
Brian Lloyd <blloyd@familyhonor.net>
Subject: Re: Build external module against Yocto kernel
Date: Wed, 16 Jan 2013 09:11:48 -0800 [thread overview]
Message-ID: <50F6DF54.2020005@linux.intel.com> (raw)
In-Reply-To: <50F5A221.2070209@windriver.com>
On 01/15/2013 10:38 AM, Bruce Ashfield wrote:
> On 13-01-15 01:26 PM, Patrick Turley wrote:
>> On Jan 15, 2013, at 12:00 PM, Bruce Ashfield <bruce.ashfield@windriver.com>
>> wrote:
>>
>>> On 13-01-15 12:54 PM, Patrick Turley wrote:
>>>> Thank you for directing me toward that documentation. As it happens, I
>>>> have already read that, and it doesn't apply.
>>>
>>> There are ways to do this, your requirement is the same as the on-target
>>> module building requirement. Have enough of the kernel source packaged
>>> to build modules on the target, after it has booted.
>>
>> Well, I still want to cross-compile them, but I see your point.
>>
>>> The trick is packaging things properly to not get binary/target elements
>>> in the SDK/native packages, and to package just enough for the build. But
>>> the issues have been explored and there was a plan. I know that Darren
>>> (cc'd) has looked into this more than I have recently.
>>>
>>> I can't locate the bugzilla entries on this at the moment, but I recall
>>> that some parts were still missing, but may be addressed in yocto 1.4,
>>> when I find the bug numbers, I'll have a better idea.
>>
>> As I expected, someone else has already thought about this. This isn't the most common approach so it makes sense that it's been a lower priority. The good news for me is that I know I'm not missing something, so I can stop looking for it.
>
> I finally found the entries that I was recalling earlier. They are:
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968
>
> 1614 and 2968 are the most interesting for what you are asking.
>
> As you can see the net result of those bugs is that you can get the
> right parts of the kernel tree in SDK packages, since they include
> dev packages, and with what is currently in kernel-dev .. it should
> be enough to build against in the SDK (perhaps with just the LDFLAGS
> tweaks mentioned in the other thread). The sources should be part
> of the sysroot, and hence available when that is packaged for use
> outside of bitbake/yocto.
>
> If you aren't seeing kernel-dev in the SDK image, it might be that
> TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something
> else is different in the SDK that is being generated in your testing.
>
> I'm only speculating about what might be missing, since I'm not 100%
> familiar with the SDK, but perhaps Jessica or others can chime in if
> I've led you astray :)
>
Thanks for keeping this going Bruce. Yes, kernel-dev is the package for
the target. The only trick here is that we currently purge the host
binaries which means that you need to build scripts on the target prior
to building the module.
I think this might be missing from the new kernel manual as it isn't a
particularly common use-case, and is rather orthogonal to the way the
tooling has been designed (not to say it can't be done).
Patrick, please keep us posted if this continues to not work for you. I
will open a bug to include a section about this in the kernel
development manual.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
next prev parent reply other threads:[~2013-01-16 17:12 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-14 23:27 Build external module against Yocto kernel Patrick Turley
2013-01-15 17:07 ` Brian Lloyd
2013-01-15 17:09 ` Brian Lloyd
2013-01-15 17:54 ` Patrick Turley
2013-01-15 18:00 ` Bruce Ashfield
2013-01-15 18:26 ` Patrick Turley
2013-01-15 18:38 ` Bruce Ashfield
2013-01-15 19:16 ` Zhang, Jessica
2013-01-22 19:52 ` Patrick Turley
2013-01-16 17:11 ` Darren Hart [this message]
2013-01-21 21:21 ` Patrick Turley
2013-01-22 12:34 ` Christian Ege
2013-01-22 20:28 ` Patrick Turley
2013-01-22 20:34 ` Bruce Ashfield
2013-01-23 2:26 ` Patrick Turley
2013-01-23 4:43 ` Bruce Ashfield
2013-01-23 5:14 ` Patrick Turley
2013-01-23 5:17 ` Bruce Ashfield
2013-01-23 5:34 ` Patrick Turley
2013-01-23 13:48 ` Bruce Ashfield
2013-01-23 15:17 ` Patrick Turley
2013-01-24 19:58 ` John Mehaffey
2013-01-24 20:10 ` Bruce Ashfield
2013-01-25 1:34 ` John Mehaffey
2013-02-01 4:50 ` Bruce Ashfield
2013-02-02 0:48 ` Patrick Turley
2013-02-02 4:35 ` Brian Lloyd
2013-02-02 4:51 ` Bruce Ashfield
2013-02-02 4:48 ` Bruce Ashfield
2013-02-02 5:12 ` Brian Lloyd
2013-02-02 5:16 ` Bruce Ashfield
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=50F6DF54.2020005@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=blloyd@familyhonor.net \
--cc=bruce.ashfield@windriver.com \
--cc=yocto@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.