From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [Xenomai-help] Running more than one "skin" at the same time? From: Philippe Gerum In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Date: Fri, 22 Sep 2006 20:33:30 +0200 Message-Id: <1158950010.5175.103.camel@domain.hid> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Reply-To: rpm@xenomai.org List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Betz Cc: xenomai@xenomai.org On Fri, 2006-09-22 at 10:37 -0700, David Betz wrote:=20 > Is it possible to run more than one skin on top of the nucleus at the > same time? For instance, can I run the pSOS skin at the same time as > the Xenomai Native API? In short, not yet. There is a timing mode compatibility issue between the native/POSIX skins and the pSOS module. This particular issue will be fixed somewhere in the 2.3.x series. You might still mix both now with a bit of hacking, but this would require that timeout values passed to pSOS calls be rescaled as counts of nanoseconds instead of ticks, which might not be an option for you. > If so, would all of the calls from a single user mode process have to > be to one of the skins or could calls be mixed? In other words, could > a single thread in a user mode process at one point block on a pSOS > semaphore and later block on a Native API semaphore? What are the > rules for mixing and matching API calls? >=20 The rule of thumb is that blocking syscalls would require to be invoked from threads created by the same skin, e.g. a pSOS sema4 would only allow pSOS tasks to pend on it, but would allow any kind of task to post it. The same goes for all calls that directly affect particular skin properties (e.g. sending signals through ev_send() must target a pSOS task). But for instance, a native task would be allowed to suspend or resume a pSOS one, since the only thing that needs to be known at that point is the target task identifier, and we basically don't care of the caller's nature. > =20 >=20 > The problem that I=E2=80=99m trying to solve is that I want to build my > software on top of the Xenomai Native API but I may have a customer > who wants to port their pSOS code onto the same platform. Is there a > way to make that work? They will sometimes need to call functions in > my firmware so will indirectly invoke Native API calls from their > pSOS-based code. >=20 >=20 A possible approach would be to make your native-based firmware appear as a set of server task(s) to the pSOS side. Those native tasks would have to wait for requests from the pSOS side sent using a native IPC (that doesn't block the caller, e.g. rt_queue_send on the pSOS side, rt_queue_receive on the native one, but NOT rt_task_send from the pSOS side, which waits for a reply thus always blocks the caller). > =20 >=20 > Thanks, >=20 > David Betz >=20 >=20 > _______________________________________________ > Xenomai-help mailing list > Xenomai-help@domain.hid > https://mail.gna.org/listinfo/xenomai-help --=20 Philippe.