From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 9 Feb 2015 16:57:16 +0100 From: Gilles Chanteperdrix Message-ID: <20150209155716.GE3200@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> <20150206161626.GD27277@hermes.click-hack.org> <54D8D7D5.2060000@control.lth.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54D8D7D5.2060000@control.lth.se> 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 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.