[Xenomai] Mixing Posix RT APIs and vxWorks APIs
alex_plits at radwin.com
Mon Apr 25 12:03:38 CEST 2016
> -----Original Message-----
> From: Philippe Gerum [mailto:rpm at xenomai.org]
> Sent: Thursday, April 07, 2016 8:56 PM
> To: Alex Plits; Gilles Chanteperdrix
> Cc: xenomai at xenomai.org
> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
> On 04/07/2016 07:56 AM, Alex Plits wrote:
> >> -----Original Message-----
> >> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix at xenomai.org]
> >> Sent: Tuesday, April 05, 2016 10:03 AM
> >> To: Alex Plits
> >> Cc: xenomai at xenomai.org
> >> Subject: Re: [Xenomai] Mixing Posix RT APIs and vxWorks APIs
> >> On Mon, Apr 04, 2016 at 01:42:11PM +0000, Alex Plits wrote:
> >>> Hi,
> >>> We are currently porting some of our vxWorks xenomai (copperplate)
> >>> APIs we use in our application to Posix (cobalt I guess).
> >> Well, if you do not know whether you are using Cobalt or Mercury, we
> >> can not know it for you...
> > [Alex Plits]
> > Cobalt :)
> >>> We have started with the VxWorks "tasks" but it seems that we're
> >>> getting strange behavior on The remaining VxWorks APIs when used
> >>> from
> >> the POSIX generated tasks (threads is the right word in posix) e.g.
> >> MsqQRecv function gets segfault but when it is used From a VxWorks
> >> generated task it works fine.
> >>> I understand from the comments in code it should work but I was
> >> wondering if there are known issues.
> >>> We are using currently xenomai 3 rc-6 (I saw there were fixes in
> >>> xenomai
> >> 3.0.2).
> >> Could you send a self-contained, simplest possible test case which
> >> causes the problem for you, that we can test on the latest Xenomai
> >> release to see if the problem has not been already fixed?
> > [Alex Plits]
> > Attached code that is ripped from xenomai examples and initiates 2
> threads using posix api then uses VxWorks MsgQ to communicate.
> > Please advise if this code works as expected - it seems that when we use
> WAIT_FOREVER flag we have an issue.
> > Sorry in advance for the #ifdef's and comments in code -
> For the record, 3.0-rc6 won't work properly with --enable-pshared setups.
> For sane shared processing involving multiple copperplate-based APIs (such
> as VxWorks), you do need 3.0.2.
We have configured --enable-pshared on xenomai 3.0.2 and now compiling empty application (just empty main routine) using non posix skin e.g. vxworks or even alchemy causes the
"Bus error" in runtime(see below). Removing --enable-pshared bootstrap completes successfully.
# ./posixvx --trace=1
-- xenomai_init() running
-- connected to Cobalt
-- memory locked
-- memory heaps mapped
More information about the Xenomai