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