Re: [Xenomai-main] Bug in xenomai on top of POSIX

[Gilles Chanteperdrix]

address@hidden wrote:
 > En réponse à Gilles Chanteperdrix <address@hidden>:
 > 
 > (...)
 > > 1- you can not hope for a tick timer frequency greater than a few tens
 > > of
 > >   hertz, even when using SCHED_FIFO scheduling policy, and the
 > >   theoretical limit is Linux tick timer frequency, 100 Hz by default,
 > >   without accounting for the jitter ; 
 > I know it, but we have a clear client constraint: 
 > make an emulator in userspace without patching the kernel! :( 
 > So no possibility to use RTAI patch....

My advice was a bit too radical. You may be willing to start using this
layer, accepting its deficiencies, all the more that it is currently the
only way to use Xenomai in user space.

 > The client propose some workaround: we use a modified version of the
 > rtc driver 
 > (loaded as module, that  by-pass the original RTC IRQ, this is ugly,
 > i know...),
 > and we have a posix-murtc rt-layer (=posix.h modified to use murtc)
 > And they beleive in the "power" of 2.6.x linux kernel, they hope in the 
 > futur,
 > it will help us in doing a more efficient emulator.... (when 2.6 will be
 > released, and integrated in some GNU/Linux distribution)
 > 

In fact, you could directly use the linux RTC driver as a timing
source (just replace setitimer in the timer thread of posix.h by some
ioctl and sigwait by read on the /dev/rtc device), but you will run into
another problem then: the jitter. Patching your kernel for low-latency
may improve the situation.

 > (...)
 > > 3- as Linux scheduler is totally unaware of Xenomai, using Linux
 > > blocking
 > >   syscalls does not lead to cooperative scheduling, all your threads
 > > are
 > >   blocked.
 > We know too, and we have to play with this, thus we place a constraint to our
 > client on using (in their application) blocking calls.... they have
 > accepted it! 

In fact this too can be worked around :
- you can use non-blocking calls ;
- you can create your own threads (using POSIX API, not the emulated
  API), which call the blocking functions and then simulate interrupts
  with a signal, just like the timer thread does.

 > > Let's make it clear : the posix.h in the cvs is only a bugfix release
 > > for the unlucky who would have already started using the POSIX layer.
 > OK, do you know what is the bug that still reside in posix.h? Perhaps we
 > can/will fix it.

The bug I mention is described in the following post: 
http://mail.gnu.org/archive/html/xenomai-main/2003-08/msg00000.html

Mr. Pulle sent me a sample of code which triggers the bug, and
contrarily to what happened with the old posix.h, it appears within
seconds with the newer posix.h. So, chances are I will find the
bug. And again : I was too radical, the POSIX layer is still supported,
at least as long RTAI/vm is not stable enough. And when RTAI/vm is
stable, the switch should be easy, anyway.


 > Sincères salutations, ;o)
People reading this list had probably noticed how poor is my english,
now they know why...

Regards.

-- 


                                            Gilles Chanteperdrix.