Re: [Xenomai-core] general questions
> 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
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. 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
[Xenomai-core] general questions
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
