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

[gagchris]

En réponse à Gilles Chanteperdrix <address@hidden>:

> address@hidden wrote:
>  > En réponse à Gilles Chanteperdrix
> <address@hidden>:
>  > 
>  > > 
>  > > Any feedback on this newer version will be appreciated.
>  > We will use xenomai on top of posix heavly, so i will send you
> feedback...
>  > 
> 
> I did not make it clear in my previous mail, but I advise you not to
> start a new project using Xenomai on top of POSIX. Even if all the
> bugs
> were corrected, this layer has a lot of deficiencies which can not be
> corrected :
> 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....
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)


> 2- the nucleus (the Xenomai core) needs to schedule its threads itself
>   and the POSIX threads interface is made to let the kernel schedule
> your
>   threads, so POSIX threads are not adapted to RTOS emulation, which
>   leads to the current heavy-weight, unefficient Xenomai POSIX layer ;
Yeah, we know the "poor" timing performance of posix layer, but for the project
the timing we measure seem to satisfy our client (the real target application
run on a address@hidden)

> 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!

> 
> I think these deficiencies are among the reasons why the Xenomai POSIX
> layer was discontinued.
Yes i'm agree with you, but posix is the one usuable on a original distribution
kernel (for us we have to use the original kernel that comes with a RH7.2)


> 
> 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.

Sincères salutations, ;o)
Christian.

> 
> Regards.
> 
> 
> 
> 
>                                           Gilles Chanteperdrix.
> 
> 
> _______________________________________________
> Xenomai-main mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/xenomai-main
>