Re: [Xenomai] Mixing linux and alchemy (cobalt) calls

[Philippe Gerum <rpm@xenomai.org>]

On 02/06/2015 03:47 PM, Anders Blomdell wrote:
> I have an application that need both realtime and linux sockets, am I correct in assuming that
> withe the alchemy skin I could access them like
> 
>   socket(...           // Linux version
>   __real_socket(...    // Linux version
>   __cobalt_socket(...  // Alchemy/cobalt version
> 
> while under the cobalt skin, it would be:
> 
>   socket(...           // Alchemy/cobalt version
>   __real_socket(...    // Linux version
>   __cobalt_socket(...  // Alchemy/cobalt version
> 

This depends on the LDFLAGS retrieved from xeno-config:

1. with --posix mentioned in the xeno-config --ldflags request

	socket(...), __cobalt_socket(...) or __RT(socket(...))  => Cobalt
implementation
	__real_socket(...) or __STD(socket(...)) => glibc service

2. without --posix mentioned in the xeno-config --ldflags request

	__cobalt_socket(...) or __RT(socket(...))  => Cobalt implementation
	socket(...) or __STD(socket(...)) => glibc service

e.g.

- the application only wants to access the POSIX services implemented by
Cobalt using the regular POSIX names: LDFLAGS should contain the output of:
$ xeno-config --posix --ldflags, or --cobalt --ldflags.

- the application wants to access the POSIX services implemented by
Cobalt using the regular POSIX names, and the alchemy API: LDFLAGS
should contain the output of:
$ xeno-config --posix --alchemy --ldflags, or --cobalt --alchemy --ldflags.

- the application wants to access the POSIX services implemented by
Cobalt solely via the explicit POSIX wrappers, and the alchemy API:
LDFLAGS should contain the output of (i.e. omitting --posix):
$ xeno-config --alchemy --ldflags, or --alchemy --ldflags.

NOTE: using __RT() is preferred to calling __cobalt(), in case an API
stacked over the Cobalt POSIX API redefines its own implementation of
POSIX services over the dual kernel. __RT() would call the stacked
implementation, __cobalt() would force a call to the Cobalt
implementation of the service.

-- 
Philippe.