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

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

[roderik.wildenburg]

I have build a library which makes use of some Xenomai-Posix functions (mainly shared memory but also some semaphore functions). This library provides functions (logging) which should be used by Xenomai tasks and Linux processes.
When I link this new library with a standard linux process, this process obviously becomes automatically a Xenomai task (task is listed in /proc/xenomai/sched) just by linking with my library (not even calling a xeno-function is necessary). 
Unfortunatelly this seems also to have an influence on the scheduling policy and the priority of the linux process:

When I set the policy (to SCHED_FIFO) and the priority of this linux process (by an external startup process) with :
	p.sched_priority = somepriority;
	sched_setscheduler(pidoflinuxprocess, SCHED_FIFO, &p);

and afterwards query the policy and priority within the process with :
	sched_getscheduler()
	sched_getparam()
I get the the policy SCHED_OTHER and a totaly different priority. This unfortunatelly prevents the linux process to be scheduled by linux as a prioritized process and therefore other prioritized processes with lower priority now are scheduled (by Linux) in front of my (normaly high prioritized) process.

After this long eplanation, which, I hope, is understandable, here my question:

How can I use Xenomai-libraries without Xenomai scheduling, or how can I build Xenomai based libraries usable for Xenomai and Linux (without influencing Linux schduling parameters)?

Unfortunatelly I don´t have a small and handy testcase at the moment, but I would create one, if you need it for answering my question.
Some additional info : I use Xenomai 2.3.5 on a PPC 2.4.25 Kernel

Thank you for your help in advance and best regards
Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

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

[Gilles Chanteperdrix]

roderik.wildenburg@domain.hid wrote:
> I have build a library which makes use of some Xenomai-Posix functions (mainly shared memory but also some semaphore functions). This library provides functions (logging) which should be used by Xenomai tasks and Linux processes.
> When I link this new library with a standard linux process, this process obviously becomes automatically a Xenomai task (task is listed in /proc/xenomai/sched) just by linking with my library (not even calling a xeno-function is necessary). 
> Unfortunatelly this seems also to have an influence on the scheduling policy and the priority of the linux process:
> 
> When I set the policy (to SCHED_FIFO) and the priority of this linux process (by an external startup process) with :
> 	p.sched_priority = somepriority;
> 	sched_setscheduler(pidoflinuxprocess, SCHED_FIFO, &p);

sched_setscheduler is not what you want, it changes the scheduling
parameters of the whole process whereas you want to change scheduling
parameters of only one thread.
So, use pthread_setschedparam instead.

-- 
                                                 Gilles.

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

[roderik.wildenburg]

> It is not your job to decide the priority of a xenomai thread when it
> runs in secondary mode, you have to set the xenomai 
> scheduler's priority
> of the thread, and xenomai itself will change the priority for linux
> scheduler. The way to do this is to call pthread_setschedparam in the
> "linuxwithxenolib" process.

You would be right if I would design a new process, but "linuxwithxenolib" is an existing (Linux) process which is just linked with my Xenomai-library and should be influenced as few as possible by my library (this process still should act as an prioritzed Linux process as far as possible). This process, and several others, are spawned by "sysup" and "sysup" sets the priority and the scheduling policy (to SCHED_FIFO) of the spawned processes. This is an existing mechanism (!) and could not changed easily, as it would have backlash to many other processes (and people -whose Xenomai skills are poor- developing these processes, ).
Additional to these ordinary Linux processes we have several pure Xenomai-processes, which of course, use pthread_setschedparam to set their scheduling parameters. These pure Xenomai-processes are also using my Xenomai-library.

>From this scenario deduce the following questions :

1.) Linking a linux-process with a Xenomai-library "transforms" the linux process to a Xenomai-process/task. Is this true ?

2.) Is there a way to influence the priority and scheduling policy of a Xenomai-task from outside the task (from an other task (like "sysup"); like sched_setscheduler can do for linux processes) ?

3.) As soon as a Xenomai-systemcall (e.g. clock_gettime, sem_post, sem_wait) is executed in this process the process is scheduled in primary mode ?

4.) Is there a way, to force back a process to secondary mode (after the Xenomai-systemcall has been executed) ?

Thank you for your patience and endurance in understanding my problem (my english probabliy isn´t very helpfull for this).

Roderik

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

[Gilles Chanteperdrix]

roderik.wildenburg@domain.hid wrote:
>> It is not your job to decide the priority of a xenomai thread when
>> it runs in secondary mode, you have to set the xenomai scheduler's
>> priority of the thread, and xenomai itself will change the priority
>> for linux scheduler. The way to do this is to call
>> pthread_setschedparam in the "linuxwithxenolib" process.
> 
> You would be right if I would design a new process, but
> "linuxwithxenolib" is an existing (Linux) process which is just
> linked with my Xenomai-library and should be influenced as few as
> possible by my library (this process still should act as an
> prioritzed Linux process as far as possible). This process, and
> several others, are spawned by "sysup" and "sysup" sets the priority
> and the scheduling policy (to SCHED_FIFO) of the spawned processes.
> This is an existing mechanism (!) and could not changed easily, as it
> would have backlash to many other processes (and people -whose
> Xenomai skills are poor- developing these processes, ). Additional to
> these ordinary Linux processes we have several pure
> Xenomai-processes, which of course, use pthread_setschedparam to set
> their scheduling parameters. These pure Xenomai-processes are also
> using my Xenomai-library.
> 
> From this scenario deduce the following questions :
> 
> 1.) Linking a linux-process with a Xenomai-library "transforms" the
> linux process to a Xenomai-process/task. Is this true ?

Yes, and you need this to be able to call Xenomai services.

For your issue, we could probably use the existing process priority
instead of forcing SCHED_OTHER, 0. But for this to work, we have to be
sure that the "sysup" process does not call sched_setscheduler too late
after the creation of the process, IOW, there is a race condition.

But I still do not understand why you can not handle this in the xenomai
library. For instance by passing the priority to an initialization
function. You would avoid the race.

> 
> 2.) Is there a way to influence the priority and scheduling policy of
> a Xenomai-task from outside the task (from an other task (like
> "sysup"); like sched_setscheduler can do for linux processes) ?

No.

> 
> 3.) As soon as a Xenomai-systemcall (e.g. clock_gettime, sem_post,
> sem_wait) is executed in this process the process is scheduled in
> primary mode ?

For some services, yes, for others no. You can find the information in
the online documentation.

> 
> 4.) Is there a way, to force back a process to secondary mode (after
> the Xenomai-systemcall has been executed) ?

Yes, but no, you do not want to do that. Xenomai automatically switches
the process when needed.

> 
> Thank you for your patience and endurance in understanding my problem
> (my english probabliy isn´t very helpfull for this).
> 
> Roderik


-- 
                                                 Gilles.

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

[roderik.wildenburg]

> > 
> > From this scenario deduce the following questions :
> > 
> > 1.) Linking a linux-process with a Xenomai-library "transforms" the
> > linux process to a Xenomai-process/task. Is this true ?
> 
> Yes, and you need this to be able to call Xenomai services.

O.k. I thought so.

> 
> For your issue, we could probably use the existing process priority
> instead of forcing SCHED_OTHER, 0. But for this to work, we have to be
> sure that the "sysup" process does not call 
> sched_setscheduler too late
> after the creation of the process, IOW, there is a race condition.

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

> 
> But I still do not understand why you can not handle this in 
> the xenomai
> library. For instance by passing the priority to an initialization
> function. You would avoid the race.
> 

The process "linuxwithxenolib" does not know anything about the priority, as "sysup" manages the scheduling parameters for him (reads configuration file,...; this has mainly historic reasons (ported from other OS)), therfore "linuxwithxenolib" can not pass the priority to my library. This is not realy very beautiful and I think we have to think about it.


> > 
> > 2.) Is there a way to influence the priority and scheduling 
> policy of
> > a Xenomai-task from outside the task (from an other task (like
> > "sysup"); like sched_setscheduler can do for linux processes) ?
> 
> No.
O.K. I probably have to accept this. So we have to think about an other solution (probably set the priority within "linuxwithxenolib"). 

> 
> > 
> > 3.) As soon as a Xenomai-systemcall (e.g. clock_gettime, sem_post,
> > sem_wait) is executed in this process the process is scheduled in
> > primary mode ?
> 
> For some services, yes, for others no. You can find the information in
> the online documentation.
> 
> > 
> > 4.) Is there a way, to force back a process to secondary mode (after
> > the Xenomai-systemcall has been executed) ?
> 
> Yes, but no, you do not want to do that. Xenomai 
> automatically switches
> the process when needed.
> 

But yes, I want, I want, I want  ;-))
Think about the following scenario:
1)"linuxwithxenolib" calls my xenomai-library. 
2)Due to a xenomai systemcall in my library "linuxwithxenolib" switches to primary mode
3)"linuxwithxenolib" leaves my library function
4)"linuxwithxenolib" is still in primary mode and acts as a realtime task till it calls a linux-systemcall.
This isn´t the way "linuxwithxenolib" should act. It should be scheduled by linux as often and as long as possible.
5)So, if I could force secondary mode at the end of my library function everything would be fine.

So how can I force secondary mode ?

Thank you very much for your help !
Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

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

[Gilles Chanteperdrix]

roderik.wildenburg@domain.hid wrote:
>>> From this scenario deduce the following questions :
>>> 
>>> 1.) Linking a linux-process with a Xenomai-library "transforms"
>>> the linux process to a Xenomai-process/task. Is this true ?
>> Yes, and you need this to be able to call Xenomai services.
> 
> O.k. I thought so.
> 
>> For your issue, we could probably use the existing process priority
>>  instead of forcing SCHED_OTHER, 0. But for this to work, we have
>> to be sure that the "sysup" process does not call 
>> sched_setscheduler too late after the creation of the process, IOW,
>> there is a race condition.
> 
> 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.


> 
>> But I still do not understand why you can not handle this in the
>> xenomai library. For instance by passing the priority to an
>> initialization function. You would avoid the race.
>> 
> 
> The process "linuxwithxenolib" does not know anything about the
> priority, as "sysup" manages the scheduling parameters for him (reads
> configuration file,...; this has mainly historic reasons (ported from
> other OS)), therfore "linuxwithxenolib" can not pass the priority to
> my library. This is not realy very beautiful and I think we have to
> think about it.
> 
> 
>>> 2.) Is there a way to influence the priority and scheduling
>> policy of
>>> a Xenomai-task from outside the task (from an other task (like 
>>> "sysup"); like sched_setscheduler can do for linux processes) ?
>> No.
> O.K. I probably have to accept this. So we have to think about an
> other solution (probably set the priority within "linuxwithxenolib").
> 
> 
>>> 3.) As soon as a Xenomai-systemcall (e.g. clock_gettime,
>>> sem_post, sem_wait) is executed in this process the process is
>>> scheduled in primary mode ?
>> For some services, yes, for others no. You can find the information
>> in the online documentation.
>> 
>>> 4.) Is there a way, to force back a process to secondary mode
>>> (after the Xenomai-systemcall has been executed) ?
>> Yes, but no, you do not want to do that. Xenomai automatically
>> switches the process when needed.
>> 
> 
> But yes, I want, I want, I want  ;-)) Think about the following
> scenario: 1)"linuxwithxenolib" calls my xenomai-library. 2)Due to a
> xenomai systemcall in my library "linuxwithxenolib" switches to
> primary mode 3)"linuxwithxenolib" leaves my library function 
> 4)"linuxwithxenolib" is still in primary mode and acts as a realtime
> task till it calls a linux-systemcall. This isn´t the way
> "linuxwithxenolib" should act. It should be scheduled by linux as
> often and as long as possible. 5)So, if I could force secondary mode
> at the end of my library function everything would be fine.
> 
> 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.
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.

-- 
                                                 Gilles.

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

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> roderik.wildenburg@domain.hid wrote:
>>>> 4.) Is there a way, to force back a process to secondary mode
>>>> (after the Xenomai-systemcall has been executed) ?
>>> Yes, but no, you do not want to do that. Xenomai automatically
>>> switches the process when needed.
>>>
>> But yes, I want, I want, I want  ;-)) Think about the following
>> scenario: 1)"linuxwithxenolib" calls my xenomai-library. 2)Due to a
>> xenomai systemcall in my library "linuxwithxenolib" switches to
>> primary mode 3)"linuxwithxenolib" leaves my library function 
>> 4)"linuxwithxenolib" is still in primary mode and acts as a realtime
>> task till it calls a linux-systemcall. This isn´t the way
>> "linuxwithxenolib" should act. It should be scheduled by linux as
>> often and as long as possible. 5)So, if I could force secondary mode
>> at the end of my library function everything would be fine.
>>
>> 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.
> 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.

The only imaginable scenario for having to force some thread back to
secondary mode is when that thread is running significant CPU load
_without_ issuing a single regular syscall. If such a thread enters
primary mode and is then left there, Linux will not be able to run
anymore. In that case one may insert a tiny nanosleep etc. to enforce
the switch. But that's still a fairly theoretic scenario.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

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

[roderik.wildenburg]

Jan Kiszka wrote:

> > 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.
> > 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.
> 
> The only imaginable scenario for having to force some thread back to
> secondary mode is when that thread is running significant CPU load
> _without_ issuing a single regular syscall. If such a thread enters
> primary mode and is then left there, Linux will not be able to run
> anymore. In that case one may insert a tiny nanosleep etc. to enforce
> the switch. But that's still a fairly theoretic scenario.
> 

But nanosleep is a Xenomai function. So, after that nanosleep the
process would return to pimary mode and run in front of all other
Xenomai tasks (a high priority provided) although it has been just an
oridnary Linux task (which has been linked with a Xenomai library) and
therefore should only run when all Xenomai processes yield CPU. Am I
right? Do you understand my dilemma ?

Best regards
Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

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

[Jan Kiszka]

roderik.wildenburg@domain.hid wrote:
> Jan Kiszka wrote:
> 
>>> 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.
>>> 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.
>> The only imaginable scenario for having to force some thread back to
>> secondary mode is when that thread is running significant CPU load
>> _without_ issuing a single regular syscall. If such a thread enters
>> primary mode and is then left there, Linux will not be able to run
>> anymore. In that case one may insert a tiny nanosleep etc. to enforce
>> the switch. But that's still a fairly theoretic scenario.
>>
> 
> But nanosleep is a Xenomai function. So, after that nanosleep the
> process would return to pimary mode and run in front of all other
> Xenomai tasks (a high priority provided) although it has been just an
> oridnary Linux task (which has been linked with a Xenomai library) and
> therefore should only run when all Xenomai processes yield CPU. Am I
> right? Do you understand my dilemma ?

Yeah, bad example. Take $YOUR_FAVORITE_CHEAP_LINUX_SYSCALL instead, for
instance syscall(SYS_pid) will be better.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

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

[roderik.wildenburg]

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

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

Best regards 
Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

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

[Gilles Chanteperdrix]

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.

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

[roderik.wildenburg]

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

Yes, but with my own words, so you can tell me whether I understood you or not ;-).

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

How are Linux tasks treated which are not linked with any Xenomay library, but whose scheduling is set to SCHED_FIFO and whose priority is set to some value higher than a Xenomai tasks (with sched_setscheduler). When do they run ?

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

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

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

[Gilles Chanteperdrix]

roderik.wildenburg@domain.hid wrote:
>>> 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.
>> 
> 
> Yes, but with my own words, so you can tell me whether I understood
> you or not ;-).

Yes you understood.

> 
>>> 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.
> 
> How are Linux tasks treated which are not linked with any Xenomay
> library, but whose scheduling is set to SCHED_FIFO and whose priority
> is set to some value higher than a Xenomai tasks (with
> sched_setscheduler). When do they run ?

They can prevent a Xenomai task running in secondary mode from running,
but not a Xenomai task running in primary mode.

-- 
                                                 Gilles.

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

[Gilles Chanteperdrix]

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 can also call sched_setscheduler after fork but before exec. In case
you want to do that, here is the (untested) patch, to let the xenomai
posix skin use this priority.

Index: src/skins/posix/init.c
===================================================================
--- src/skins/posix/init.c	(revision 4572)
+++ src/skins/posix/init.c	(working copy)
@@ -48,7 +48,7 @@ static __attribute__ ((constructor))
 void __init_posix_interface(void)
 {
 	struct sched_param parm;
-	int muxid, err;
+	int muxid, err, policy;

 	muxid =
 	    xeno_bind_skin(PSE51_SKIN_MAGIC, "POSIX", "xeno_posix");
@@ -74,9 +74,14 @@ void __init_posix_interface(void)
 		exit(EXIT_FAILURE);
 	}

-	parm.sched_priority = 0;
-	err = __wrap_pthread_setschedparam(pthread_self(), SCHED_OTHER,
-					   &parm);
+	err = __real_pthread_getschedparam(pthread_self(), &policy, &parm);
+	if (err) {
+		fprintf(stderr, "Xenomai Posix skin init: "
+			"pthread_getschedparam: %s\n", strerror(err));
+		exit(EXIT_FAILURE);
+	}
+
+	err = __wrap_pthread_setschedparam(pthread_self(), policy, &parm);
 	if (err) {
 		fprintf(stderr, "Xenomai Posix skin init: "
 			"pthread_setschedparam: %s\n", strerror(err));


-- 
                                                 Gilles.