Re: [Xenomai-help] newbie question

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

juanba romance wrote:
 > On 8/6/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
 > >
 > >
 > > What you are referring to is the priority coupling between Xenomai and
 > > Linux schedulers, and can be disabled in Xenomai configuration.
 > >
 > > The linux kernel will keep the inherited priority until the RT-task
 > > calls xenomai again, or until it is suspended by Linux scheduler. If the
 > > RT-task does not call xenomai for a while (and is not suspended by Linux
 > > scheduler), then, well, it is an RT-task after all and should be able to
 > > run until it reaches a suspension point or wakes up another RT-task.
 > 
 > Hello both, i have a newbie doubt
 > 
 > What should i understand by a "xenomai" call ?
 > Does it simple means to call a symbol owned by the xenomai libs ?

To summarize, we could say yes. But the situation is a little bit more
complicated. Not all symbol owned by the Xenomai libs cause user-space
applications to switch to primary mode. So, an RT-task will remain in
secondary mode until it calls one of the Xenomai services which cause
their caller to switch to primary mode.

 > 
 > Note however that during this time, Linux interruptions will be allowed
 > > to preempt the RT-task.
 > >
 > I think  that if one design a source thread/rt-task whatever which is
 > focused on rt constrains,
 > one would like to acquire ASAP the same rt-context free of such preempt
 > policy.

There is an option of Xenomai which prevents Linux interruptions from
preempting an RT-task in secondary mode, it is called "interrupt shield"
but is disabled by default.

But you should understand that when you design a system "focused on rt
constraints", your rt task should remain in primary mode. When going to
secondary mode, you are loosing some determinism, because Xenomai may
have to wait an unbounded time before the migrating task is allowed to
run. Secondary mode is convenient for initializations (your system is
not yet real-time), and for tasks which live near the frontier between
real-time and non real-time world.

 > Right now i can hold a exhaustive monitoring related on my performed systems
 > calls
 > but i also suppose that at same place/time i will need some linux
 > service, and therefore a good practice could be quite useful, any hint
 > about?

The only advice I can give you is not to call directly a Linux service
from a task which is doing some real-time job. If you want to call some
linux service call it from a task which will communicate with the
real-time job using one of the IPCs proposed by Xenomai. Of course your
real-time job should not depend on timely execution of the Linux
service, otherwise you would loose determinism again.

-- 


					    Gilles Chanteperdrix.