* Formulating Recipe for out-of-tree kernel module
@ 2016-05-09 11:15 Chris Trobridge
2016-05-10 6:59 ` Chris Trobridge
0 siblings, 1 reply; 7+ messages in thread
From: Chris Trobridge @ 2016-05-09 11:15 UTC (permalink / raw)
To: yocto
[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]
I am looking to produce a recipe for the amfeltec usb-fxs adaptor (http://amfeltec.com/products/piranha-usb-fxs-adapter/), with the intention of contributing this to the meta-telephony layer.
However, I have found a few obstacles to getting a clean recipe:The makefile produces both a kernel module and a user utility, with the latter being hard-coded to build with g++. I can produce a recipe to produce one or other of the components but not both. Given the structure of the build directories, should this be be achievable, or should I be spitting up the recipe in two?Dahdi header files and Modules.symvers are required. A header file is used to deduce the version of Dahdi, Modules.symvers is required for the module build process. Hence, requires the location of the Dahdi source/build directory. This can be set relative to the amfeltec work directory but this feels wrong.
In more general terms my questions are:Should I split a recipe into kernel and non-kernel components?How should one out-of-tree recipe access the headers/Module.symvers from another (should that recipe be installing them in ${STAGING_KERNEL_DIR} (or somewhere else)?)
Cheers,Chris
[-- Attachment #2: Type: text/html, Size: 1782 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Formulating Recipe for out-of-tree kernel module
2016-05-09 11:15 Formulating Recipe for out-of-tree kernel module Chris Trobridge
@ 2016-05-10 6:59 ` Chris Trobridge
2016-05-10 10:06 ` Esponde, Joel
0 siblings, 1 reply; 7+ messages in thread
From: Chris Trobridge @ 2016-05-10 6:59 UTC (permalink / raw)
To: yocto
[-- Attachment #1: Type: text/plain, Size: 2168 bytes --]
At the risk of answering my own question...
Splitting a driver package into a module recipe and a separate recipe for user-mode utilities works in that each recipe uses the appropriate build process and puts files in the appropriate subdirectory of /work/.
I still don't see a way to build one out-of-tree module against another. I am interested in opinion on this. Should I try to get these drivers built in tree? They seem to be the only two out-of-tree drivers in the build at present. There is also some facility to add extra modules to the dahdi linux build, although achieving this with bitbake could be challenging too.
Cheers,Chris
From: christrobridge@hotmail.com
To: yocto@yoctoproject.org
Date: Mon, 9 May 2016 12:15:26 +0100
Subject: [yocto] Formulating Recipe for out-of-tree kernel module
I am looking to produce a recipe for the amfeltec usb-fxs adaptor (http://amfeltec.com/products/piranha-usb-fxs-adapter/), with the intention of contributing this to the meta-telephony layer.
However, I have found a few obstacles to getting a clean recipe:The makefile produces both a kernel module and a user utility, with the latter being hard-coded to build with g++. I can produce a recipe to produce one or other of the components but not both. Given the structure of the build directories, should this be be achievable, or should I be spitting up the recipe in two?Dahdi header files and Modules.symvers are required. A header file is used to deduce the version of Dahdi, Modules.symvers is required for the module build process. Hence, requires the location of the Dahdi source/build directory. This can be set relative to the amfeltec work directory but this feels wrong.
In more general terms my questions are:Should I split a recipe into kernel and non-kernel components?How should one out-of-tree recipe access the headers/Module.symvers from another (should that recipe be installing them in ${STAGING_KERNEL_DIR} (or somewhere else)?)
Cheers,Chris
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[-- Attachment #2: Type: text/html, Size: 3076 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Formulating Recipe for out-of-tree kernel module
2016-05-10 6:59 ` Chris Trobridge
@ 2016-05-10 10:06 ` Esponde, Joel
2016-05-10 11:28 ` Chris Trobridge
0 siblings, 1 reply; 7+ messages in thread
From: Esponde, Joel @ 2016-05-10 10:06 UTC (permalink / raw)
To: Chris Trobridge, yocto
[-- Attachment #1: Type: text/plain, Size: 3065 bytes --]
Hi,
There is a bitbake issue that prevents building an out-of-tree module that is dependent of another out-of-tree module.
This issue has been fixed recently:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next&id=a9cc27e6916e5affe8b0cc431c3e89abd7681643
This fix has been released on yocto 2.1 (krogoth).
So if you are using an older Yocto project, you will have to fix two recipes manually.
I hope this will help!
Joël Esponde
Honeywell | Sensing and Productivity Solutions
De : yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] De la part de Chris Trobridge
Envoyé : mardi 10 mai 2016 08:59
À : yocto@yoctoproject.org
Objet : Re: [yocto] Formulating Recipe for out-of-tree kernel module
At the risk of answering my own question...
Splitting a driver package into a module recipe and a separate recipe for user-mode utilities works in that each recipe uses the appropriate build process and puts files in the appropriate subdirectory of /work/.
I still don't see a way to build one out-of-tree module against another. I am interested in opinion on this. Should I try to get these drivers built in tree? They seem to be the only two out-of-tree drivers in the build at present. There is also some facility to add extra modules to the dahdi linux build, although achieving this with bitbake could be challenging too.
Cheers,
Chris
________________________________
From: christrobridge@hotmail.com<mailto:christrobridge@hotmail.com>
To: yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Date: Mon, 9 May 2016 12:15:26 +0100
Subject: [yocto] Formulating Recipe for out-of-tree kernel module
I am looking to produce a recipe for the amfeltec usb-fxs adaptor (http://amfeltec.com/products/piranha-usb-fxs-adapter/), with the intention of contributing this to the meta-telephony layer.
However, I have found a few obstacles to getting a clean recipe:
* The makefile produces both a kernel module and a user utility, with the latter being hard-coded to build with g++. I can produce a recipe to produce one or other of the components but not both. Given the structure of the build directories, should this be be achievable, or should I be spitting up the recipe in two?
* Dahdi header files and Modules.symvers are required. A header file is used to deduce the version of Dahdi, Modules.symvers is required for the module build process. Hence, requires the location of the Dahdi source/build directory. This can be set relative to the amfeltec work directory but this feels wrong.
In more general terms my questions are:
* Should I split a recipe into kernel and non-kernel components?
* How should one out-of-tree recipe access the headers/Module.symvers from another (should that recipe be installing them in ${STAGING_KERNEL_DIR} (or somewhere else)?)
Cheers,
Chris
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto
[-- Attachment #2: Type: text/html, Size: 21216 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Formulating Recipe for out-of-tree kernel module
2016-05-10 10:06 ` Esponde, Joel
@ 2016-05-10 11:28 ` Chris Trobridge
2016-05-10 13:29 ` Esponde, Joel
0 siblings, 1 reply; 7+ messages in thread
From: Chris Trobridge @ 2016-05-10 11:28 UTC (permalink / raw)
To: Esponde, Joel, yocto
[-- Attachment #1: Type: text/plain, Size: 3988 bytes --]
Thanks Joel,
I am on Krogoth.
My reading of that patch is that it allows out-of-tree modules to depend on symbols from the kernel but I don't see how it would help with depending on another out-of-tree module? Those symbols are not added to the kernel Module.symvers.
I've been following some other usage I read that 'out-of-tree' means compiling outside/after the kernel build, which may not be 100% accurate?
Anyway, it suggests to me that copying the first module's Module.symvers to the shared kernel staging area and then referencing that from the second module is probably better than my current solution, provided I don't break any conventions on using the staging area.
Cheers,Chris
From: Joel.Esponde@Honeywell.com
To: christrobridge@hotmail.com; yocto@yoctoproject.org
Subject: RE: [yocto] Formulating Recipe for out-of-tree kernel module
Date: Tue, 10 May 2016 10:06:37 +0000
Hi,
There is a bitbake issue that prevents building an out-of-tree module that is dependent of another out-of-tree module.
This issue has been fixed recently:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next&id=a9cc27e6916e5affe8b0cc431c3e89abd7681643
This fix has been released on yocto 2.1 (krogoth).
So if you are using an older Yocto project, you will have to fix two recipes manually.
I hope this will help!
Joël Esponde
Honeywell
| Sensing and Productivity Solutions
De : yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org]
De la part de Chris Trobridge
Envoyé : mardi 10 mai 2016 08:59
À : yocto@yoctoproject.org
Objet : Re: [yocto] Formulating Recipe for out-of-tree kernel module
At the risk of answering my own question...
Splitting a driver package into a module recipe and a separate recipe for user-mode utilities works in that each recipe uses the appropriate build process and puts files in the
appropriate subdirectory of /work/.
I still don't see a way to build one out-of-tree module against another. I am interested in opinion on this. Should I try to get these drivers built in tree? They seem to be
the only two out-of-tree drivers in the build at present. There is also some facility to add extra modules to the dahdi linux build, although achieving this with bitbake could be challenging too.
Cheers,
Chris
From:
christrobridge@hotmail.com
To: yocto@yoctoproject.org
Date: Mon, 9 May 2016 12:15:26 +0100
Subject: [yocto] Formulating Recipe for out-of-tree kernel module
I am looking to produce a recipe for the amfeltec usb-fxs adaptor (http://amfeltec.com/products/piranha-usb-fxs-adapter/),
with the intention of contributing this to the meta-telephony layer.
However, I have found a few obstacles to getting a clean recipe:
The makefile produces both a kernel module and a user utility, with the latter being hard-coded to build with g++. I can produce a recipe to produce one or other of the components but not both. Given
the structure of the build directories, should this be be achievable, or should I be spitting up the recipe in two?
Dahdi header files and Modules.symvers are required. A header file is used to deduce the version of Dahdi, Modules.symvers is required for the module build process. Hence, requires the location of
the Dahdi source/build directory. This can be set relative to the amfeltec work directory but this feels wrong.
In more general terms my questions are:
Should I split a recipe into kernel and non-kernel components?
How should one out-of-tree recipe access the headers/Module.symvers from another (should that recipe be installing them in ${STAGING_KERNEL_DIR} (or somewhere else)?)
Cheers,
Chris
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[-- Attachment #2: Type: text/html, Size: 12013 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Formulating Recipe for out-of-tree kernel module
2016-05-10 11:28 ` Chris Trobridge
@ 2016-05-10 13:29 ` Esponde, Joel
2016-05-10 13:57 ` Chris Trobridge
0 siblings, 1 reply; 7+ messages in thread
From: Esponde, Joel @ 2016-05-10 13:29 UTC (permalink / raw)
To: Chris Trobridge, yocto
[-- Attachment #1: Type: text/plain, Size: 4800 bytes --]
Ok! I better understand your need now.
The fix solves the case where an out of tree module is dependent of a kernel module which is not built as a built-in module.
Just in case, did you have a look on these links?
http://stackoverflow.com/a/33718934/1729117
https://www.kernel.org/doc/Documentation/kbuild/modules.txt (Chapter 6.2 and 6.3)
Joël Esponde
Honeywell | Sensing and Productivity Solutions
De : Chris Trobridge [mailto:christrobridge@hotmail.com]
Envoyé : mardi 10 mai 2016 13:28
À : Esponde, Joel; yocto@yoctoproject.org
Objet : RE: [yocto] Formulating Recipe for out-of-tree kernel module
Thanks Joel,
I am on Krogoth.
My reading of that patch is that it allows out-of-tree modules to depend on symbols from the kernel but I don't see how it would help with depending on another out-of-tree module? Those symbols are not added to the kernel Module.symvers.
I've been following some other usage I read that 'out-of-tree' means compiling outside/after the kernel build, which may not be 100% accurate?
Anyway, it suggests to me that copying the first module's Module.symvers to the shared kernel staging area and then referencing that from the second module is probably better than my current solution, provided I don't break any conventions on using the staging area.
Cheers,
Chris
________________________________
From: Joel.Esponde@Honeywell.com<mailto:Joel.Esponde@Honeywell.com>
To: christrobridge@hotmail.com<mailto:christrobridge@hotmail.com>; yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Subject: RE: [yocto] Formulating Recipe for out-of-tree kernel module
Date: Tue, 10 May 2016 10:06:37 +0000
Hi,
There is a bitbake issue that prevents building an out-of-tree module that is dependent of another out-of-tree module.
This issue has been fixed recently:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next&id=a9cc27e6916e5affe8b0cc431c3e89abd7681643
This fix has been released on yocto 2.1 (krogoth).
So if you are using an older Yocto project, you will have to fix two recipes manually.
I hope this will help!
Joël Esponde
Honeywell | Sensing and Productivity Solutions
De : yocto-bounces@yoctoproject.org<mailto:yocto-bounces@yoctoproject.org> [mailto:yocto-bounces@yoctoproject.org] De la part de Chris Trobridge
Envoyé : mardi 10 mai 2016 08:59
À : yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Objet : Re: [yocto] Formulating Recipe for out-of-tree kernel module
At the risk of answering my own question...
Splitting a driver package into a module recipe and a separate recipe for user-mode utilities works in that each recipe uses the appropriate build process and puts files in the appropriate subdirectory of /work/.
I still don't see a way to build one out-of-tree module against another. I am interested in opinion on this. Should I try to get these drivers built in tree? They seem to be the only two out-of-tree drivers in the build at present. There is also some facility to add extra modules to the dahdi linux build, although achieving this with bitbake could be challenging too.
Cheers,
Chris
________________________________
From: christrobridge@hotmail.com<mailto:christrobridge@hotmail.com>
To: yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Date: Mon, 9 May 2016 12:15:26 +0100
Subject: [yocto] Formulating Recipe for out-of-tree kernel module
I am looking to produce a recipe for the amfeltec usb-fxs adaptor (http://amfeltec.com/products/piranha-usb-fxs-adapter/), with the intention of contributing this to the meta-telephony layer.
However, I have found a few obstacles to getting a clean recipe:
* The makefile produces both a kernel module and a user utility, with the latter being hard-coded to build with g++. I can produce a recipe to produce one or other of the components but not both. Given the structure of the build directories, should this be be achievable, or should I be spitting up the recipe in two?
* Dahdi header files and Modules.symvers are required. A header file is used to deduce the version of Dahdi, Modules.symvers is required for the module build process. Hence, requires the location of the Dahdi source/build directory. This can be set relative to the amfeltec work directory but this feels wrong.
In more general terms my questions are:
* Should I split a recipe into kernel and non-kernel components?
* How should one out-of-tree recipe access the headers/Module.symvers from another (should that recipe be installing them in ${STAGING_KERNEL_DIR} (or somewhere else)?)
Cheers,
Chris
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto
[-- Attachment #2: Type: text/html, Size: 30792 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Formulating Recipe for out-of-tree kernel module
2016-05-10 13:29 ` Esponde, Joel
@ 2016-05-10 13:57 ` Chris Trobridge
2016-05-10 18:16 ` Bruce Ashfield
0 siblings, 1 reply; 7+ messages in thread
From: Chris Trobridge @ 2016-05-10 13:57 UTC (permalink / raw)
To: Esponde, Joel, yocto
[-- Attachment #1: Type: text/plain, Size: 5585 bytes --]
Thanks Joel,
I can build the module but I am trying to find out the best way to do this with yocto/bitbake.
The build process for the second module I have requires the location of the first and then does copy the Module.symvers and accesses the header files and ".version" file.
The question was more about how it should find these.
What I have just tried out, is to copy the above files (Module.symvers, .version and include/* to ${STAGING_KERNEL_BUILDDIR}/out-of-tree/${PN}, which is hence easily accessible by the second recipe.
This works but may not be the preferred way? I suspect the preferred way is to build in the kernel.
Cheers,Chris
From: Joel.Esponde@Honeywell.com
To: christrobridge@hotmail.com; yocto@yoctoproject.org
Subject: RE: [yocto] Formulating Recipe for out-of-tree kernel module
Date: Tue, 10 May 2016 13:29:30 +0000
Ok! I better understand your need now.
The fix solves the case where an out of tree module is dependent of a kernel module which is not built as a built-in module.
Just in case, did you have a look on these links?
http://stackoverflow.com/a/33718934/1729117
https://www.kernel.org/doc/Documentation/kbuild/modules.txt
(Chapter 6.2 and 6.3)
Joël Esponde
Honeywell
| Sensing and Productivity Solutions
De : Chris Trobridge [mailto:christrobridge@hotmail.com]
Envoyé : mardi 10 mai 2016 13:28
À : Esponde, Joel; yocto@yoctoproject.org
Objet : RE: [yocto] Formulating Recipe for out-of-tree kernel module
Thanks Joel,
I am on Krogoth.
My reading of that patch is that it allows out-of-tree modules to depend on symbols from the kernel but I don't see how it would help with depending on another out-of-tree module?
Those symbols are not added to the kernel Module.symvers.
I've been following some other usage I read that 'out-of-tree' means compiling outside/after the kernel build, which may not be 100% accurate?
Anyway, it suggests to me that copying the first module's Module.symvers to the shared kernel staging area and then referencing that from the second module is probably better than
my current solution, provided I don't break any conventions on using the staging area.
Cheers,
Chris
From:
Joel.Esponde@Honeywell.com
To: christrobridge@hotmail.com;
yocto@yoctoproject.org
Subject: RE: [yocto] Formulating Recipe for out-of-tree kernel module
Date: Tue, 10 May 2016 10:06:37 +0000
Hi,
There is a bitbake issue that prevents building an out-of-tree module that is dependent of another out-of-tree module.
This issue has been fixed recently:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next&id=a9cc27e6916e5affe8b0cc431c3e89abd7681643
This fix has been released on yocto 2.1 (krogoth).
So if you are using an older Yocto project, you will have to fix two recipes manually.
I hope this will help!
Joël Esponde
Honeywell
| Sensing and Productivity Solutions
De :
yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org]
De la part de Chris Trobridge
Envoyé : mardi 10 mai 2016 08:59
À : yocto@yoctoproject.org
Objet : Re: [yocto] Formulating Recipe for out-of-tree kernel module
At the risk of answering my own question...
Splitting a driver package into a module recipe and a separate recipe for user-mode utilities works in that each recipe uses the appropriate build process and puts files in the
appropriate subdirectory of /work/.
I still don't see a way to build one out-of-tree module against another. I am interested in opinion on this. Should I try to get these drivers built in tree? They seem to be
the only two out-of-tree drivers in the build at present. There is also some facility to add extra modules to the dahdi linux build, although achieving this with bitbake could be challenging too.
Cheers,
Chris
From:
christrobridge@hotmail.com
To: yocto@yoctoproject.org
Date: Mon, 9 May 2016 12:15:26 +0100
Subject: [yocto] Formulating Recipe for out-of-tree kernel module
I am looking to produce a recipe for the amfeltec usb-fxs adaptor (http://amfeltec.com/products/piranha-usb-fxs-adapter/),
with the intention of contributing this to the meta-telephony layer.
However, I have found a few obstacles to getting a clean recipe:
The makefile produces both a kernel module and a user utility, with the latter being hard-coded to build with g++. I can produce a recipe to produce one or other of the components but not both. Given
the structure of the build directories, should this be be achievable, or should I be spitting up the recipe in two?
Dahdi header files and Modules.symvers are required. A header file is used to deduce the version of Dahdi, Modules.symvers is required for the module build process. Hence, requires the location of
the Dahdi source/build directory. This can be set relative to the amfeltec work directory but this feels wrong.
In more general terms my questions are:
Should I split a recipe into kernel and non-kernel components?
How should one out-of-tree recipe access the headers/Module.symvers from another (should that recipe be installing them in ${STAGING_KERNEL_DIR} (or somewhere else)?)
Cheers,
Chris
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[-- Attachment #2: Type: text/html, Size: 21047 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Formulating Recipe for out-of-tree kernel module
2016-05-10 13:57 ` Chris Trobridge
@ 2016-05-10 18:16 ` Bruce Ashfield
0 siblings, 0 replies; 7+ messages in thread
From: Bruce Ashfield @ 2016-05-10 18:16 UTC (permalink / raw)
To: Chris Trobridge, Esponde, Joel, yocto
On 2016-05-10 9:57 AM, Chris Trobridge wrote:
> Thanks Joel,
>
> I can build the module but I am trying to find out the best way to do
> this with yocto/bitbake.
>
> The build process for the second module I have requires the location of
> the first and then does copy the Module.symvers and accesses the header
> files and ".version" file.
>
> The question was more about how it should find these.
>
> What I have just tried out, is to copy the above files (Module.symvers,
> .version and include/* to ${STAGING_KERNEL_BUILDDIR}/out-of-tree/${PN},
> which is hence easily accessible by the second recipe.
>
> This works but may not be the preferred way? I suspect the preferred
> way is to build in the kernel.
Having two external modules that depend on symbols is indeed a case
that isn't explicitly in the current workflow. As was pointed out, we
did solve the case where an external module required symbols from
a module from the kernel (that extra copy to the shared workdir of the
updated Module.symvers).
If you have two out of tree modules that have a dependency, then you
do need to arrange to have the symbol information available to the
second module. What you did is pretty much the right way, you could
also update the kernel shared workdir, but you'd have to be careful
to not race with the main build, and also to not clobber symbols from
the kernel and in-tree modules.
Bruce
>
> Cheers,
> Chris
>
> ------------------------------------------------------------------------
> From: Joel.Esponde@Honeywell.com
> To: christrobridge@hotmail.com; yocto@yoctoproject.org
> Subject: RE: [yocto] Formulating Recipe for out-of-tree kernel module
> Date: Tue, 10 May 2016 13:29:30 +0000
>
> Ok! I better understand your need now.
>
> The fix solves the case where an out of tree module is dependent of a
> kernel module which is not built as a built-in module.
>
>
>
> Just in case, did you have a look on these links?
>
> http://stackoverflow.com/a/33718934/1729117
>
> https://www.kernel.org/doc/Documentation/kbuild/modules.txt (Chapter 6.2
> and 6.3)
>
>
>
> *Joël Esponde*
>
> *Honeywell *| Sensing and Productivity Solutions
>
>
>
> *De :*Chris Trobridge [mailto:christrobridge@hotmail.com]
> *Envoyé :* mardi 10 mai 2016 13:28
> *À :* Esponde, Joel; yocto@yoctoproject.org
> *Objet :* RE: [yocto] Formulating Recipe for out-of-tree kernel module
>
>
>
> Thanks Joel,
>
>
>
> I am on Krogoth.
>
>
>
> My reading of that patch is that it allows out-of-tree modules to depend
> on symbols from the kernel but I don't see how it would help with
> depending on another out-of-tree module? Those symbols are not added to
> the kernel Module.symvers.
>
>
>
> I've been following some other usage I read that 'out-of-tree' means
> compiling outside/after the kernel build, which may not be 100% accurate?
>
>
>
> Anyway, it suggests to me that copying the first module's Module.symvers
> to the shared kernel staging area and then referencing that from the
> second module is probably better than my current solution, provided I
> don't break any conventions on using the staging area.
>
>
>
> Cheers,
>
> Chris
>
> ------------------------------------------------------------------------
>
> From: Joel.Esponde@Honeywell.com <mailto:Joel.Esponde@Honeywell.com>
> To: christrobridge@hotmail.com <mailto:christrobridge@hotmail.com>;
> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
> Subject: RE: [yocto] Formulating Recipe for out-of-tree kernel module
> Date: Tue, 10 May 2016 10:06:37 +0000
>
> Hi,
>
>
>
> There is a bitbake issue that prevents building an out-of-tree module
> that is dependent of another out-of-tree module.
>
> This issue has been fixed recently:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next&id=a9cc27e6916e5affe8b0cc431c3e89abd7681643
>
>
>
> This fix has been released on yocto 2.1 (krogoth).
>
> So if you are using an older Yocto project, you will have to fix two
> recipes manually.
>
>
>
> I hope this will help!
>
>
>
> *Joël Esponde*
>
> *Honeywell *| Sensing and Productivity Solutions
>
>
>
> *De :*yocto-bounces@yoctoproject.org
> <mailto:yocto-bounces@yoctoproject.org>[mailto:yocto-bounces@yoctoproject.org]
> *De la part de* Chris Trobridge
> *Envoyé :* mardi 10 mai 2016 08:59
> *À :* yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
> *Objet :* Re: [yocto] Formulating Recipe for out-of-tree kernel module
>
>
>
> At the risk of answering my own question...
>
>
>
> Splitting a driver package into a module recipe and a separate recipe
> for user-mode utilities works in that each recipe uses the appropriate
> build process and puts files in the appropriate subdirectory of /work/.
>
>
>
> I still don't see a way to build one out-of-tree module against another.
> I am interested in opinion on this. Should I try to get these drivers
> built in tree? They seem to be the only two out-of-tree drivers in the
> build at present. There is also some facility to add extra modules to
> the dahdi linux build, although achieving this with bitbake could be
> challenging too.
>
> Cheers,
>
> Chris
>
> ------------------------------------------------------------------------
>
> From: christrobridge@hotmail.com <mailto:christrobridge@hotmail.com>
> To: yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
> Date: Mon, 9 May 2016 12:15:26 +0100
> Subject: [yocto] Formulating Recipe for out-of-tree kernel module
>
> I am looking to produce a recipe for the amfeltec usb-fxs adaptor
> (http://amfeltec.com/products/piranha-usb-fxs-adapter/), with the
> intention of contributing this to the meta-telephony layer.
>
>
>
> However, I have found a few obstacles to getting a clean recipe:
>
> * The makefile produces both a kernel module and a user utility, with
> the latter being hard-coded to build with g++. I can produce a
> recipe to produce one or other of the components but not both.
> Given the structure of the build directories, should this be be
> achievable, or should I be spitting up the recipe in two?
> * Dahdi header files and Modules.symvers are required. A header file
> is used to deduce the version of Dahdi, Modules.symvers is required
> for the module build process. Hence, requires the location of the
> Dahdi source/build directory. This can be set relative to the
> amfeltec work directory but this feels wrong.
>
>
>
> In more general terms my questions are:
>
> * Should I split a recipe into kernel and non-kernel components?
> * How should one out-of-tree recipe access the headers/Module.symvers
> from another (should that recipe be installing them in
> ${STAGING_KERNEL_DIR} (or somewhere else)?)
>
>
>
> Cheers,
>
> Chris
>
>
>
>
> -- _______________________________________________ yocto mailing list
> yocto@yoctoproject.org
> <mailto:yocto@yoctoproject.org>https://lists.yoctoproject.org/listinfo/yocto
>
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-05-10 18:16 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-09 11:15 Formulating Recipe for out-of-tree kernel module Chris Trobridge
2016-05-10 6:59 ` Chris Trobridge
2016-05-10 10:06 ` Esponde, Joel
2016-05-10 11:28 ` Chris Trobridge
2016-05-10 13:29 ` Esponde, Joel
2016-05-10 13:57 ` Chris Trobridge
2016-05-10 18:16 ` Bruce Ashfield
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.