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.espo...@honeywell.com
To: christrobri...@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:christrobri...@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.espo...@honeywell.com

To: christrobri...@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-boun...@yoctoproject.org [mailto:yocto-boun...@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:
christrobri...@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









                                          
-- 
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to