Re: [Xenomai-help] How to use Xenomai libraries with "normal" (non Xenomai) linux processes ?

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

roderik.wildenburg@domain.hid wrote:
> Sorry for the delayed answer, but I am fighting with an other Xenomai
> problem too (PPC switchtest FPU problem, you probably heard about
> it).
> 
>>> I don´t understand this. Isn´t this a contradiction to your
>> answer in
>>> 2.) ? I thought sched_setscheduler does not work for Xenomai
>>> tasks and in our testcase we could see that scheduling policy
>>> isn´t set as expected (to SCHED_FIFO).
>> Currently the posix skin library does, in init.c: 
>> parm.sched_priority = 0; err =
>> __wrap_pthread_setschedparam(pthread_self(), SCHED_OTHER, &parm);
>> 
>> We could replace this with: err =
>> pthread_getschedparam(pthread_self(), &policy, &parm); if (err) ...
>>  err = __wrap_pthread_setschedparam(pthread_self(), policy, &parm);
>> 
>> 
>> But sched_setscheduler could be called after that, so this is racy.
>> 
> 
> Please correct me if I am wrong: In your replacement
> pthread_getschedparam would read scheduling parameters which should
> have been set with sched_setscheduler before(!) your replacement gets
> active. Is this possible at all ? Wouldn´t I have to call
> sched_setscheduler (in "sysup") before I fork? And if calling after
> the fork it realy would be racy. So this isn´t a very feasible
> solution, isn´t it? Changing the scheduling paramters of a running
> Xenoami task probably isn´t possible (probably there is nothing to
> recognize the change ?)?

You are just repeating what I said. So, I have not much more to say.

> 
>>> So how can I force secondary mode ?
>> The point is that if you force it to secondary mode, and the next
>> system call is in fact a xenomai syscall, xenomai will switch the
>> thread to primary mode again. So, you have two useless mode
>> switches which you could have avoided if you had not forcibly
>> switched to secondary mode.
> 
> In our case this wouldn´t be very likely and even if there would be 2
> useless mode switches, I could accept this as it would happen "only"
> in a Linux (not realtime) process (I would force back to secondary
> mode only if I knew it is a Linux, not Xenomai process).
> 
>> Note that even if a xenomai thread is running in secondary mode and
>> has a priority higher than another xenomai thread running in
>> primary mode, the one running in secondary mode will run. So, you
>> should not use primary mode and secondary mode to decide which
>> thread should run, you should use the priorities.
> 
> This is realy astonishing! I didn´t knew that and even now I can´t
> believe it. I allways thought that secondary mode means: scheduled by
> Linux and Linux is the lowest priority task in Xenomai. So, as soon
> as a task is in secondary mode every(!) Xenomai primary mode task
> would be scheduled in front of a secondary mode task, I thought. So,
> if your statement is right, I can´t see the difference between
> primary and secondary mode any more as a higher prioritized task
> obviously allways(!?) runs in front of a lower prioritized one
> independend whether it runs in primary or secondary mode? Is there
> some documenation I could read for better understanding ? Is this
> behaviour connected to the Xenomai "priority coupling" option?

Yes, it is what priority coupling means. But it really is the most sane
behaviour: you choose a priority and both Linux and Xenomai schedulers
cooperate to enfore this priority.
The real difference between a task running in secondary mode and a task
running in primary mode, is that a task running in secondary mode may be
interrupted/preempted by a Linux event. So, running in primary mode is
not a problem in itself as you seem to think. Provided that the priority
are well chosen, it will not prevent other task from running.

-- 
                                                 Gilles.