[Xenomai] Porting a library to Xenomai

Gilles Chanteperdrix gilles.chanteperdrix at xenomai.org
Fri Dec 11 14:20:12 CET 2015


On Fri, Dec 11, 2015 at 01:44:01PM +0100, Leopold Palomo-Avellaneda wrote:
> Hi,
> 
> I'm working to make a library to work with Xenomai. It's a library that has a 
> thread and open a socket to communicate with an external device via network.
> 
> I have read the guide "Porting a Linux application to Xenomai dual kernel [1]" 
> but still I have some doubts in some details. So, here my topics without any 
> importance order:
> 
> - What is the recommended way to obtain the link, flags, etc information to 
> build an application that use Xenomai? xeno-config, pkg-config, some build 
> macros to find the information, ... 

Quoting the document you say you have read:
"Compilation flags

To ease that task, the xeno-config script, installed when compiling
Xenomai user-space support, is able to give you these flags. (...) 
Beware: this way of obtaining the compilation flags is recommended,
if for anything because it will make using a different release of
Xenomai easier: the flags may change between two different releases." 

> 
> - I would like to have a code that could be used with an Standard POSIX or a 
> Xenomai. I thought that protecting my code with some #ifdef __XENO__ I could 
> choose which part is specific to Xenomai and which no. However, I'm a bit 
> confused, because then, I don't understand what is the utility of the wrap 
> script. Please, could you elaborate a bit more this part, especially focused 
> in an application the could use an standard network interface or rtnet 
> version.

Quoting the documentation again: "Use of Linux original services

It may happen that you would like to use Linux services instead of
Xenomai POSIX skin overloaded services. In this case, the –wrap
mechanism described in section Under the hood: the –wrap flag.
offers a solution: prefix the name of the service you would like to
use with the __real_ prefix, such as, for instance
__real_pthread_create.

If you do that, and would still want to be able to compile your
application without Xenomai (it may be a good idea, as it allows,
for instance, to run your application with valgrind, which you can
not do with an application compiled for Xenomai), Xenomai
compilation flags define a preprocessor macro (__XENO__) which
allows you to know whether or not you are compiling the application
for Xenomai. You can use it for instance in the following way:

 /* Open a plain Linux UDP socket. */
 #ifndef __XENO__
       fd = socket(PF_INET, SOCK_DGRAM, 0);
 #else /* __XENO__ */
       fd = __real_socket(PF_INET, SOCK_DGRAM, 0);
 #endif /* __XENO__ */
"

> 
> - In the document, there's a section about the mlockall option. So, may I 
> understand that from xenomai <= 2.6.3 it's not needed that I call the mlockall 
> function?

Quoting the documentation again: "
Starting with version 2.6.3, as part of their initialization,
Xenomai libraries systematically call mlockall to commit and lock
the whole application memory.
(...)
Before version 2.6.3

Xenomai POSIX library only invoked mlockall if the
–enable-posix-auto-mlockall option was passed to the configure
script when compiling Xenomai user-space support. So, applications
which did not want to depend on this configuration had to call
mlockall by themselves, before using any Xenomai service, by using: 

 mlockall(MCL_CURRENT | MCL_FUTURE);"


-- 
					    Gilles.
https://click-hack.org



More information about the Xenomai mailing list