From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 6 Feb 2015 17:16:26 +0100 From: Gilles Chanteperdrix Message-ID: <20150206161626.GD27277@hermes.click-hack.org> References: <54D4D409.2020708@control.lth.se> <54D4D9B2.8090805@xenomai.org> <54D4DF0C.2080007@control.lth.se> <54D4E285.9000906@xenomai.org> <54D4E44B.4060403@control.lth.se> <20150206161215.GC27277@hermes.click-hack.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150206161215.GC27277@hermes.click-hack.org> Subject: Re: [Xenomai] Mixing linux and alchemy (cobalt) calls List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anders Blomdell Cc: "Xenomai@xenomai.org" 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.