[Xenomai-help] Running more than one "skin" at the same time?

[Xenomai-help] Running more than one "skin" at the same time?

[David Betz]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

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? 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?

 

The problem that I'm 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.

 

Thanks,

David Betz


[-- Attachment #2: Type: text/html, Size: 2353 bytes --]

Re: [Xenomai-help] Running more than one "skin" at the same time?

[Philippe Gerum]

On Fri, 2006-09-22 at 10:37 -0700, David Betz wrote: 
> 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?
> 

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.

>  
> 
> The problem that I’m 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.
> 
> 

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

>  
> 
> Thanks,
> 
> David Betz
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] Running more than one "skin" at the same time?

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > On Fri, 2006-09-22 at 10:37 -0700, David Betz wrote: 
 > > 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.

It is also possible to run the native and POSIX skins in periodic mode.

 > > 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?
 > > 
 > 
 > 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.

A word about the posix skin: only services related to signals and
cancellation absolutely require posix skin threads, all other services,
including synchronization objects and message queues are accessible from
other skins threads.


-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] Running more than one "skin" at the same time?

[Philippe Gerum]

On Fri, 2006-09-22 at 22:48 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > On Fri, 2006-09-22 at 10:37 -0700, David Betz wrote: 
>  > > 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.
> 
> It is also possible to run the native and POSIX skins in periodic mode.
> 

It really depends on which skin provides the time base. If it's pSOS,
then every skin would be happy to use the periodic mode as the pSOS
emulator does. If you implement services over the native/posix skin
requiring precise timing such as for accurate data sampling that feeds
data to the pSOS application in turn, then periodic timing for all won't
fly, at least until the periodic mode is eventually emulated over the
oneshot mode as planned.

>  > > 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?
>  > > 
>  > 
>  > 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.
> 
> A word about the posix skin: only services related to signals and
> cancellation absolutely require posix skin threads, all other services,
> including synchronization objects and message queues are accessible from
> other skins threads.

Unfortunately, we cannot do that on the same scale for the native one,
since many synchronization objects there require to hold some data in
the native task control block, and we could not reasonably stuff them
into the control block of the underlying generic nucleus threads. So
David, unless you are absolutely fond of the native API, you may want to
consider using the POSIX skin instead; this would likely ease your work.

> 
> 
-- 
Philippe.