[Xenomai] Mixing linux and alchemy (cobalt) calls

[Xenomai] Mixing linux and alchemy (cobalt) calls

[Anders Blomdell]

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


/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

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

[Philippe Gerum]

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.

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

[Anders Blomdell]

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 :-).

/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

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

[Philippe Gerum]

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.

-- 
Philippe.

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

[Anders Blomdell]

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.

/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

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

[Gilles Chanteperdrix]

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.

-- 
					    Gilles.

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

[Gilles Chanteperdrix]

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.

-- 
					    Gilles.

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

[Anders Blomdell]

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

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

[Gilles Chanteperdrix]

On Mon, Feb 09, 2015 at 04:52:53PM +0100, Anders Blomdell wrote:
> 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?

You are comparing user-space code with kernel space code. In xenomai
2.6, the user-space code you should be looking at is
src/skins/posix/rtdm.c

And in that code __wrap_socket falls back to __real_socket if the
kernel-space code returns one of the known errors.

Now the real question is: what arguments do you pass to the cobalt
rt socket call? If these arguments are the one corresponding to the
socket protocol implemented by the rtpacket module, the behaviour
you observe is normal, otherwise, this is a bug.

-- 
					    Gilles.

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

[Anders Blomdell]

On 2015-02-09 16:57, Gilles Chanteperdrix wrote:
> On Mon, Feb 09, 2015 at 04:52:53PM +0100, Anders Blomdell wrote:
>> 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?
> 
> You are comparing user-space code with kernel space code. In xenomai
> 2.6, the user-space code you should be looking at is
> src/skins/posix/rtdm.c
Even from native mode (which is what I use in 2.6)?

> And in that code __wrap_socket falls back to __real_socket if the
> kernel-space code returns one of the known errors.
> 
> Now the real question is: what arguments do you pass to the cobalt
> rt socket call? If these arguments are the one corresponding to the
> socket protocol implemented by the rtpacket module, the behaviour
> you observe is normal, otherwise, this is a bug.
I don't say it's a bug, but to me it seems like alchemy differs from
the old native skin in this case.

/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

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

[Gilles Chanteperdrix]

On Mon, Feb 09, 2015 at 05:10:51PM +0100, Anders Blomdell wrote:
> On 2015-02-09 16:57, Gilles Chanteperdrix wrote:
> > On Mon, Feb 09, 2015 at 04:52:53PM +0100, Anders Blomdell wrote:
> >> 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?
> > 
> > You are comparing user-space code with kernel space code. In xenomai
> > 2.6, the user-space code you should be looking at is
> > src/skins/posix/rtdm.c
> Even from native mode (which is what I use in 2.6)?

In that case, you should look at src/skins/rtdm/core.c
The services rt_dev_socket belongs to the rtdm skin not to native
skin.

> 
> > And in that code __wrap_socket falls back to __real_socket if the
> > kernel-space code returns one of the known errors.
> > 
> > Now the real question is: what arguments do you pass to the cobalt
> > rt socket call? If these arguments are the one corresponding to the
> > socket protocol implemented by the rtpacket module, the behaviour
> > you observe is normal, otherwise, this is a bug.
> I don't say it's a bug, but to me it seems like alchemy differs from
> the old native skin in this case.

Well, not really, the native skin never had a socket call anyway,
and alchemy does not either. It is just that the rtdm skin
disappeared, so now you use the cobalt service instead of the rtdm
skin.

-- 
					    Gilles.

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

[Anders Blomdell]

On 2015-02-09 17:24, Gilles Chanteperdrix wrote:
> On Mon, Feb 09, 2015 at 05:10:51PM +0100, Anders Blomdell wrote:
>> On 2015-02-09 16:57, Gilles Chanteperdrix wrote:
>>> On Mon, Feb 09, 2015 at 04:52:53PM +0100, Anders Blomdell wrote:
>>>> 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?
>>>
>>> You are comparing user-space code with kernel space code. In xenomai
>>> 2.6, the user-space code you should be looking at is
>>> src/skins/posix/rtdm.c
>> Even from native mode (which is what I use in 2.6)?
> 
> In that case, you should look at src/skins/rtdm/core.c
> The services rt_dev_socket belongs to the rtdm skin not to native
> skin.
I stand humbly corrected.

> 
>>
>>> And in that code __wrap_socket falls back to __real_socket if the
>>> kernel-space code returns one of the known errors.
>>>
>>> Now the real question is: what arguments do you pass to the cobalt
>>> rt socket call? If these arguments are the one corresponding to the
>>> socket protocol implemented by the rtpacket module, the behaviour
>>> you observe is normal, otherwise, this is a bug.
>> I don't say it's a bug, but to me it seems like alchemy differs from
>> the old native skin in this case.
> 
> Well, not really, the native skin never had a socket call anyway,
> and alchemy does not either. It is just that the rtdm skin
> disappeared, so now you use the cobalt service instead of the rtdm
> skin.
# /usr/xenomai/bin/xeno-config --version
3.0-rc2
# usr/xenomai/bin/xeno-config --help
Usage xeno-config OPTIONS
Options :
        --help
        --v,--verbose
        --version
        --cc
        --ccld
        --arch
        --prefix
        --[skin=]posix/cobalt|vxworks|psos|alchemy|rtdm|smokey

--rtdm is there, bug?

Is there any way to check if a returned filedescriptor is a __RT or __STD one?

/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

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

[Philippe Gerum]

On 02/09/2015 06:02 PM, Anders Blomdell wrote:
> On 2015-02-09 17:24, Gilles Chanteperdrix wrote:
>> On Mon, Feb 09, 2015 at 05:10:51PM +0100, Anders Blomdell wrote:
>>> On 2015-02-09 16:57, Gilles Chanteperdrix wrote:
>>>> On Mon, Feb 09, 2015 at 04:52:53PM +0100, Anders Blomdell wrote:
>>>>> 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?
>>>>
>>>> You are comparing user-space code with kernel space code. In xenomai
>>>> 2.6, the user-space code you should be looking at is
>>>> src/skins/posix/rtdm.c
>>> Even from native mode (which is what I use in 2.6)?
>>
>> In that case, you should look at src/skins/rtdm/core.c
>> The services rt_dev_socket belongs to the rtdm skin not to native
>> skin.
> I stand humbly corrected.
> 
>>
>>>
>>>> And in that code __wrap_socket falls back to __real_socket if the
>>>> kernel-space code returns one of the known errors.
>>>>
>>>> Now the real question is: what arguments do you pass to the cobalt
>>>> rt socket call? If these arguments are the one corresponding to the
>>>> socket protocol implemented by the rtpacket module, the behaviour
>>>> you observe is normal, otherwise, this is a bug.
>>> I don't say it's a bug, but to me it seems like alchemy differs from
>>> the old native skin in this case.
>>
>> Well, not really, the native skin never had a socket call anyway,
>> and alchemy does not either. It is just that the rtdm skin
>> disappeared, so now you use the cobalt service instead of the rtdm
>> skin.
> # /usr/xenomai/bin/xeno-config --version
> 3.0-rc2
> # usr/xenomai/bin/xeno-config --help
> Usage xeno-config OPTIONS
> Options :
>         --help
>         --v,--verbose
>         --version
>         --cc
>         --ccld
>         --arch
>         --prefix
>         --[skin=]posix/cobalt|vxworks|psos|alchemy|rtdm|smokey
> 
> --rtdm is there, bug?
>

--rtdm --kcflags can be used in x3 for retrieving the kernel CFLAGS for
building a RTDM driver. --rtdm --cflags just returns the same as --posix
--cflags.

> Is there any way to check if a returned filedescriptor is a __RT or __STD one?
> 

Not using the old 2.x trick of testing the value. RTDM fildes are mere
Linux ones now. Any RTDM fildes will answer the ioctl(RTIOC_DEVICE_INFO)
request, non-RTDM ones won't.

-- 
Philippe.

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

[Philippe Gerum]

On 02/09/2015 06:02 PM, Anders Blomdell wrote:
> On 2015-02-09 17:24, Gilles Chanteperdrix wrote:
>> On Mon, Feb 09, 2015 at 05:10:51PM +0100, Anders Blomdell wrote:
>>> On 2015-02-09 16:57, Gilles Chanteperdrix wrote:
>>>> On Mon, Feb 09, 2015 at 04:52:53PM +0100, Anders Blomdell wrote:
>>>>> 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?
>>>>
>>>> You are comparing user-space code with kernel space code. In xenomai
>>>> 2.6, the user-space code you should be looking at is
>>>> src/skins/posix/rtdm.c
>>> Even from native mode (which is what I use in 2.6)?
>>
>> In that case, you should look at src/skins/rtdm/core.c
>> The services rt_dev_socket belongs to the rtdm skin not to native
>> skin.
> I stand humbly corrected.
> 
>>
>>>
>>>> And in that code __wrap_socket falls back to __real_socket if the
>>>> kernel-space code returns one of the known errors.
>>>>
>>>> Now the real question is: what arguments do you pass to the cobalt
>>>> rt socket call? If these arguments are the one corresponding to the
>>>> socket protocol implemented by the rtpacket module, the behaviour
>>>> you observe is normal, otherwise, this is a bug.
>>> I don't say it's a bug, but to me it seems like alchemy differs from
>>> the old native skin in this case.
>>
>> Well, not really, the native skin never had a socket call anyway,
>> and alchemy does not either. It is just that the rtdm skin
>> disappeared, so now you use the cobalt service instead of the rtdm
>> skin.
> # /usr/xenomai/bin/xeno-config --version
> 3.0-rc2
> # usr/xenomai/bin/xeno-config --help
> Usage xeno-config OPTIONS
> Options :
>         --help
>         --v,--verbose
>         --version
>         --cc
>         --ccld
>         --arch
>         --prefix
>         --[skin=]posix/cobalt|vxworks|psos|alchemy|rtdm|smokey
> 
> --rtdm is there, bug?

The ambiguous rt_dev_*() API has been obsoleted, since any application
can now use the POSIX call (all apps have libcobalt underneath). Compat
wrappers should be provided by libtrank though, I'll push this before 3.0.

We will then have:

- rtdm_open/read/write...() => inter-driver calls, kernel-space only
- open/read/write...() => RTDM service calls for applications
- rt_dev_open/read/write...() => compat wrappers from libtrank to
open/read/write...(), for 2.x apps that need them.

-- 
Philippe.

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

[Anders Blomdell]

On 2015-02-09 18:27, Philippe Gerum wrote:
> On 02/09/2015 06:02 PM, Anders Blomdell wrote:
>> On 2015-02-09 17:24, Gilles Chanteperdrix wrote:
>>> On Mon, Feb 09, 2015 at 05:10:51PM +0100, Anders Blomdell wrote:
>>>> On 2015-02-09 16:57, Gilles Chanteperdrix wrote:
>>>>> On Mon, Feb 09, 2015 at 04:52:53PM +0100, Anders Blomdell wrote:
>>>>>> 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?
>>>>>
>>>>> You are comparing user-space code with kernel space code. In xenomai
>>>>> 2.6, the user-space code you should be looking at is
>>>>> src/skins/posix/rtdm.c
>>>> Even from native mode (which is what I use in 2.6)?
>>>
>>> In that case, you should look at src/skins/rtdm/core.c
>>> The services rt_dev_socket belongs to the rtdm skin not to native
>>> skin.
>> I stand humbly corrected.
>>
>>>
>>>>
>>>>> And in that code __wrap_socket falls back to __real_socket if the
>>>>> kernel-space code returns one of the known errors.
>>>>>
>>>>> Now the real question is: what arguments do you pass to the cobalt
>>>>> rt socket call? If these arguments are the one corresponding to the
>>>>> socket protocol implemented by the rtpacket module, the behaviour
>>>>> you observe is normal, otherwise, this is a bug.
>>>> I don't say it's a bug, but to me it seems like alchemy differs from
>>>> the old native skin in this case.
>>>
>>> Well, not really, the native skin never had a socket call anyway,
>>> and alchemy does not either. It is just that the rtdm skin
>>> disappeared, so now you use the cobalt service instead of the rtdm
>>> skin.
>> # /usr/xenomai/bin/xeno-config --version
>> 3.0-rc2
>> # usr/xenomai/bin/xeno-config --help
>> Usage xeno-config OPTIONS
>> Options :
>>         --help
>>         --v,--verbose
>>         --version
>>         --cc
>>         --ccld
>>         --arch
>>         --prefix
>>         --[skin=]posix/cobalt|vxworks|psos|alchemy|rtdm|smokey
>>
>> --rtdm is there, bug?
> 
> The ambiguous rt_dev_*() API has been obsoleted, since any application
> can now use the POSIX call (all apps have libcobalt underneath). Compat
> wrappers should be provided by libtrank though, I'll push this before 3.0.
> 
> We will then have:
> 
> - rtdm_open/read/write...() => inter-driver calls, kernel-space only
> - open/read/write...() => RTDM service calls for applications
> - rt_dev_open/read/write...() => compat wrappers from libtrank to
> open/read/write...(), for 2.x apps that need them.

Ok, so for libraries where I don't know which skin will be used for linking, the 
best way would be to use __RT(...) for the calls, thereby forcing the symbol 
to be whatever the skin --cflags stipulates (if I don't use __RT, the symbol
might unwrapped at link time), and then do an ioctl(RTIOC_DEVICE_INFO) to check
that I really got a realtime filedescriptor?

/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

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

[Philippe Gerum]

On 02/09/2015 06:38 PM, Anders Blomdell wrote:
> On 2015-02-09 18:27, Philippe Gerum wrote:
>> On 02/09/2015 06:02 PM, Anders Blomdell wrote:
>>> On 2015-02-09 17:24, Gilles Chanteperdrix wrote:
>>>> On Mon, Feb 09, 2015 at 05:10:51PM +0100, Anders Blomdell wrote:
>>>>> On 2015-02-09 16:57, Gilles Chanteperdrix wrote:
>>>>>> On Mon, Feb 09, 2015 at 04:52:53PM +0100, Anders Blomdell wrote:
>>>>>>> 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?
>>>>>>
>>>>>> You are comparing user-space code with kernel space code. In xenomai
>>>>>> 2.6, the user-space code you should be looking at is
>>>>>> src/skins/posix/rtdm.c
>>>>> Even from native mode (which is what I use in 2.6)?
>>>>
>>>> In that case, you should look at src/skins/rtdm/core.c
>>>> The services rt_dev_socket belongs to the rtdm skin not to native
>>>> skin.
>>> I stand humbly corrected.
>>>
>>>>
>>>>>
>>>>>> And in that code __wrap_socket falls back to __real_socket if the
>>>>>> kernel-space code returns one of the known errors.
>>>>>>
>>>>>> Now the real question is: what arguments do you pass to the cobalt
>>>>>> rt socket call? If these arguments are the one corresponding to the
>>>>>> socket protocol implemented by the rtpacket module, the behaviour
>>>>>> you observe is normal, otherwise, this is a bug.
>>>>> I don't say it's a bug, but to me it seems like alchemy differs from
>>>>> the old native skin in this case.
>>>>
>>>> Well, not really, the native skin never had a socket call anyway,
>>>> and alchemy does not either. It is just that the rtdm skin
>>>> disappeared, so now you use the cobalt service instead of the rtdm
>>>> skin.
>>> # /usr/xenomai/bin/xeno-config --version
>>> 3.0-rc2
>>> # usr/xenomai/bin/xeno-config --help
>>> Usage xeno-config OPTIONS
>>> Options :
>>>         --help
>>>         --v,--verbose
>>>         --version
>>>         --cc
>>>         --ccld
>>>         --arch
>>>         --prefix
>>>         --[skin=]posix/cobalt|vxworks|psos|alchemy|rtdm|smokey
>>>
>>> --rtdm is there, bug?
>>
>> The ambiguous rt_dev_*() API has been obsoleted, since any application
>> can now use the POSIX call (all apps have libcobalt underneath). Compat
>> wrappers should be provided by libtrank though, I'll push this before 3.0.
>>
>> We will then have:
>>
>> - rtdm_open/read/write...() => inter-driver calls, kernel-space only
>> - open/read/write...() => RTDM service calls for applications
>> - rt_dev_open/read/write...() => compat wrappers from libtrank to
>> open/read/write...(), for 2.x apps that need them.
> 
> Ok, so for libraries where I don't know which skin will be used for linking, the 
> best way would be to use __RT(...) for the calls, thereby forcing the symbol 
> to be whatever the skin --cflags stipulates (if I don't use __RT, the symbol
> might unwrapped at link time), 

Yes, forcing __RT() is the way to make sure that the wrapper for that
symbol will be called over Cobalt, regardless of whether --wrap was
mentioned in the link flags. Using this in API-neutral libs makes sense.
Over Mercury, __RT() has no effect and just returns the argument unchanged.

and then do an ioctl(RTIOC_DEVICE_INFO) to check
> that I really got a realtime filedescriptor?
> 

Yes.

-- 
Philippe.

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

[Anders Blomdell]

On 2015-02-09 21:08, Philippe Gerum wrote:
> On 02/09/2015 06:38 PM, Anders Blomdell wrote:
>> On 2015-02-09 18:27, Philippe Gerum wrote:
>>> On 02/09/2015 06:02 PM, Anders Blomdell wrote:
>>>> On 2015-02-09 17:24, Gilles Chanteperdrix wrote:
>>>>> On Mon, Feb 09, 2015 at 05:10:51PM +0100, Anders Blomdell wrote:
>>>>>> On 2015-02-09 16:57, Gilles Chanteperdrix wrote:
>>>>>>> On Mon, Feb 09, 2015 at 04:52:53PM +0100, Anders Blomdell wrote:
>>>>>>>> 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?
>>>>>>>
>>>>>>> You are comparing user-space code with kernel space code. In xenomai
>>>>>>> 2.6, the user-space code you should be looking at is
>>>>>>> src/skins/posix/rtdm.c
>>>>>> Even from native mode (which is what I use in 2.6)?
>>>>>
>>>>> In that case, you should look at src/skins/rtdm/core.c
>>>>> The services rt_dev_socket belongs to the rtdm skin not to native
>>>>> skin.
>>>> I stand humbly corrected.
>>>>
>>>>>
>>>>>>
>>>>>>> And in that code __wrap_socket falls back to __real_socket if the
>>>>>>> kernel-space code returns one of the known errors.
>>>>>>>
>>>>>>> Now the real question is: what arguments do you pass to the cobalt
>>>>>>> rt socket call? If these arguments are the one corresponding to the
>>>>>>> socket protocol implemented by the rtpacket module, the behaviour
>>>>>>> you observe is normal, otherwise, this is a bug.
>>>>>> I don't say it's a bug, but to me it seems like alchemy differs from
>>>>>> the old native skin in this case.
>>>>>
>>>>> Well, not really, the native skin never had a socket call anyway,
>>>>> and alchemy does not either. It is just that the rtdm skin
>>>>> disappeared, so now you use the cobalt service instead of the rtdm
>>>>> skin.
>>>> # /usr/xenomai/bin/xeno-config --version
>>>> 3.0-rc2
>>>> # usr/xenomai/bin/xeno-config --help
>>>> Usage xeno-config OPTIONS
>>>> Options :
>>>>         --help
>>>>         --v,--verbose
>>>>         --version
>>>>         --cc
>>>>         --ccld
>>>>         --arch
>>>>         --prefix
>>>>         --[skin=]posix/cobalt|vxworks|psos|alchemy|rtdm|smokey
>>>>
>>>> --rtdm is there, bug?
>>>
>>> The ambiguous rt_dev_*() API has been obsoleted, since any application
>>> can now use the POSIX call (all apps have libcobalt underneath). Compat
>>> wrappers should be provided by libtrank though, I'll push this before 3.0.
>>>
>>> We will then have:
>>>
>>> - rtdm_open/read/write...() => inter-driver calls, kernel-space only
>>> - open/read/write...() => RTDM service calls for applications
>>> - rt_dev_open/read/write...() => compat wrappers from libtrank to
>>> open/read/write...(), for 2.x apps that need them.
>>
>> Ok, so for libraries where I don't know which skin will be used for linking, the 
>> best way would be to use __RT(...) for the calls, thereby forcing the symbol 
>> to be whatever the skin --cflags stipulates (if I don't use __RT, the symbol
>> might unwrapped at link time), 
> 
> Yes, forcing __RT() is the way to make sure that the wrapper for that
> symbol will be called over Cobalt, regardless of whether --wrap was
> mentioned in the link flags. Using this in API-neutral libs makes sense.
> Over Mercury, __RT() has no effect and just returns the argument unchanged.
> 
> and then do an ioctl(RTIOC_DEVICE_INFO) to check
>> that I really got a realtime filedescriptor?
>>
> 
> Yes.
> 
Philippe and Gilles: big thanks for the clarifications and patience.

/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