> Date: Thu, 29 Dec 2011 15:36:07 +0100
> From: r...@xenomai.org
> To: jan0...@hotmail.de
> CC: xenomai-core@gna.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@gna.org
> > https://mail.gna.org/listinfo/xenomai-core
> 
> 
> -- 
> Philippe.                                       
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to