From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <50CCB183.70407@xenomai.org> Date: Sat, 15 Dec 2012 18:21:07 +0100 From: Philippe Gerum MIME-Version: 1.0 References: <50CC690C.9040806@xenomai.org> In-Reply-To: <50CC690C.9040806@xenomai.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] Timer support in user-space List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org On 12/15/2012 01:11 PM, Gilles Chanteperdrix wrote: > On 12/12/2012 05:26 PM, dave.joynson@alstom.com wrote: > >> Hi, >> I have recently started to use Xenomai on Raspberry Pi. My experience with >> Linux Kernel building etc. is zero so I downloaded the pre-built image >> from powet.eu. I have successfully created a cross compile environment to >> create user-space applications using the Posix skin. While tracking down >> some mode changes I came across the limitation of Posix skin Timers in >> that the timer expiry creates a signal which causes a mode switch. > > > Yes that is a shame. To finish the posix timers implementation, we need > to implement signals for xenomai tasks. Thanks to the work made on the > watchdog code, we now have everything needed, but implementing signals > is trickier as it seems, in particular because it involves > saving/restoring fpu contexts, and we know by experience that we never > got code touching FPU right the first time. > > So, in the mean time, you can use native skin timers. > >> I have considered creating an application layer timer module using a pool >> of threads that use nanosleep and a callback function on expiry. Careful >> management of these threads using a custom timer API could fulfill my >> requirements. >> While exploring the documentation for alternatives, I noticed that the >> RTDM Driver Development API provides access to native timers that would >> seem to perform the functionality that I need, On trying to use them in a >> user-space application, however, it seems that they may only be used in >> kernel-space. This leads me to the following question: >> >> Is the documentation incorrect for rtdm_timer_init() when it says >> it may be used in user-space tasks? > > >>>From what I understand, the only RTDM services available to user-space > tasks are the posix open/close/ead/write/ioctl services. So, everything > else happens in kernel-space, and when I read that an RTDM service is > available to user-space tasks, I understand that it is available on the > context of a user-space task running kernel-space code, such as a driver > callback. But I may be wrong, and it may be actually a cut and paste error. > No, the documentation is really about mentioning directly callable APIs, otherwise you might also consider all the linux kernel API as being available to userland by mean of driver handlers, which would be quite confusing. -- Philippe.