[Xenomai-core] general questions

[Xenomai-core] general questions

[Jan-Erik Lange]

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


Hello,
I'm new in the topic about the Xenomai co-kernel approach and I have some questions to the primary mode and secondary mode. 
 
I have trouble with the imagination of the fact in general, that one task (process oder thread) can be processed by two kernels (Xenomai nucleus and standard kernel), and treated by the one in real time and by the other in non real-time.
 
1. So far I understood this approach, the primary and secondary mode is an abstract description of the fact, that threads or processes can be scheduled by the Xenomai nucleus or by the standard Linux kernel scheduler. Is this correct?
 
2. Now supose, that I have chosen the VxWork-skin and I started a task in the primary mode. Is it correct that when this task is calling a non VxWork-API-funtion, there will a change of the context from primary to the secondary mode? Or what is the exact condition of the switching of the context?
 
It would be very nice, if you could tell me a little bit about these questions?
 
Best regards 
Jan 		 	   		  

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

Re: [Xenomai-core] general questions

[Philippe Gerum]

On 12/29/2011 01:04 PM, Jan-Erik Lange wrote:
> Hello,
> I'm new in the topic about the Xenomai co-kernel approach and I have
> some questions to the primary mode and secondary mode.
>
> I have trouble with the imagination of the fact in general, that one
> task (process oder thread) can be processed by two kernels (Xenomai
> nucleus and standard kernel), and treated by the one in real time and by
> the other in non real-time.
>
> 1. So far I understood this approach, the primary and secondary mode is
> an abstract description of the fact, that threads or processes can be
> scheduled by the Xenomai nucleus or by the standard Linux kernel
> scheduler. Is this correct?

Yes. A Xenomai thread in user-space is attached a "shadow" control area 
in addition to the regular linux context data, which enables both linux 
and the nucleus to schedule it in a mutually exclusive manner.

>
> 2. Now supose, that I have chosen the VxWork-skin and I started a task
> in the primary mode. Is it correct that when this task is calling a non
> VxWork-API-funtion, there will a change of the context from primary to
> the secondary mode? Or what is the exact condition of the switching of
> the context?
>

- invoking a regular linux syscall
- receiving a linux signal (e.g. kill(2) and GDB)
- causing a CPU trap (e.g. invalid memory access), hitting a breakpoint 
(e.g. GDB)

all these situations cause the switch from primary to secondary mode. We 
say that such thread "relaxes" in Xenomai parlance.

A common caveat is to call a glibc routine, which eventually issues a 
linux syscall under the hood. Think of malloc() detecting a process 
memory shortage, which then calls mmap or sbrk to extend the process 
data. Or, running into a mutex contention once in a while, forcing the 
calling thread to issue a syscall for sleeping on the mutex. 
Fortunately, we have a tool to detect these situations.

> It would be very nice, if you could tell me a little bit about these
> questions?
>
> Best regards
> Jan
>
>
>
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core


-- 
Philippe.

Re: [Xenomai-core] general questions

[Jan-Erik Lange]

> Date: Thu, 29 Dec 2011 15:36:07 +0100
> From: rpm@xenomai.org
> To: jan0385@domain.hid
> CC: xenomai@xenomai.org
> Subject: Re: [Xenomai-core] general questions
> 
> On 12/29/2011 01:04 PM, Jan-Erik Lange wrote:
> > Hello,
> > I'm new in the topic about the Xenomai co-kernel approach and I have
> > some questions to the primary mode and secondary mode.
> >
> > I have trouble with the imagination of the fact in general, that one
> > task (process oder thread) can be processed by two kernels (Xenomai
> > nucleus and standard kernel), and treated by the one in real time and by
> > the other in non real-time.
> >
> > 1. So far I understood this approach, the primary and secondary mode is
> > an abstract description of the fact, that threads or processes can be
> > scheduled by the Xenomai nucleus or by the standard Linux kernel
> > scheduler. Is this correct?
> 
> Yes. A Xenomai thread in user-space is attached a "shadow" control area 
> in addition to the regular linux context data, which enables both linux 
> and the nucleus to schedule it in a mutually exclusive manner.
> 
> >
> > 2. Now supose, that I have chosen the VxWork-skin and I started a task
> > in the primary mode. Is it correct that when this task is calling a non
> > VxWork-API-funtion, there will a change of the context from primary to
> > the secondary mode? Or what is the exact condition of the switching of
> > the context?
> >
> 
> - invoking a regular linux syscall
> - receiving a linux signal (e.g. kill(2) and GDB)
> - causing a CPU trap (e.g. invalid memory access), hitting a breakpoint 
> (e.g. GDB)
> 
> all these situations cause the switch from primary to secondary mode. We 
> say that such thread "relaxes" in Xenomai parlance.
> 
> A common caveat is to call a glibc routine, which eventually issues a 
> linux syscall under the hood. Think of malloc() detecting a process 
> memory shortage, which then calls mmap or sbrk to extend the process 
> data. Or, running into a mutex contention once in a while, forcing the 
> calling thread to issue a syscall for sleeping on the mutex. 
> Fortunately, we have a tool to detect these situations.
 
 
 
 
What is the name of the tool to detect these migrations? I thought there is only the possibility to react on this SIGXCPU signal with a signal handler.
 
 

> 
> > It would be very nice, if you could tell me a little bit about these
> > questions?
> >
> > Best regards
> > Jan
> >
> >
> >
> > _______________________________________________
> > Xenomai-core mailing list
> > Xenomai-core@domain.hid
> > https://mail.gna.org/listinfo/xenomai-core
> 
> 
> -- 
> Philippe.