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

[Anders Blomdell <anders.blomdell@control.lth.se>]

On 2015-02-06 17:16, Gilles Chanteperdrix wrote:
> On Fri, Feb 06, 2015 at 05:12:15PM +0100, Gilles Chanteperdrix wrote:
>> On Fri, Feb 06, 2015 at 04:56:59PM +0100, Anders Blomdell wrote:
>>> On 2015-02-06 16:49, Philippe Gerum wrote:
>>>> On 02/06/2015 04:34 PM, Anders Blomdell wrote:
>>>>> On 2015-02-06 16:11, Philippe Gerum wrote:
>>>>>> 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.
>>>>>>
>>>>> Thanks for the clarification, will sprinkle the code with __STD(...) 
>>>>> and __RT(...), from here on :-).
>>>>>
>>>>
>>>> That's only required if you want your code to unambiguously route to the
>>>> proper service in case the default symbol wrapping does not fit, or is
>>>> not present. This is typically what libcopperplate does, so that
>>>> non-POSIX apps can link against it, without being required to wrap the
>>>> POSIX symbols in the final executable.
>>>
>>> More to avoid me shooting myself in the foot when trying to juggle sockets
>>> from two different domains (also makes the code less dependent on the linker
>>> flags given). Already got bitten by 'modprobe rtpacket' not loading properly
>>> and the __wrap_socket picking up the posix version. And of course making the 
>>> code clearly document what belongs where.
>>
>> Not loading rtpacket should cause __wrap_socket to use the posix
>> version only if you are trying to create a socket type that the
>> rtpacket module implements. Otherwise, this is a bug.
> 
> And unless code has changed between 2.x and 3.x in this area, using
> __RT() will result in exactly the same behaviour.

You might be right, but AFAICT, on 2.6.2.1 'int __rt_dev_socket(...)' 
(ksrc/skins/rtdm/core.c) calls 'struct rtdm_device *get_protocol_device(...)' 
(ksrc/skins/rtdm/device.c), while in xenomai3/next 'COBALT_IMPL(int, socket,...)'
does a 'XENOMAI_SYSCALL3(sc_cobalt_socket, ...)' and then does a failover to
'_STD(socket, ...)' in case of -ENOSYS (which is what I believe an unloaded rt_packet.ko
gives as a result).

Am I missing something obvious?

/Anders

-- 
Anders Blomdell                  Email: anders.blomdell@control.lth.se
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden