[fusion] userspace POSIX skin

Jan Kiszka jan.kiszka at web.de
Thu Jun 16 21:35:08 CEST 2005


Hi all,

kind of late reply to the mails I received privately last week by 
Philippe and others, but after my first experiments failed, I wanted to 
have a closer look before jumping in the discussion. However, things are 
still broken, more about this later.

First of all, the POSIX userspace skin is a really nice thing! 
RTAI/fusion now has a semantically compatible interface for normal 
userspace programs. However the userspace library may look like, the 
kernel interface is ready to be used! I'm not totally happy with the 
naming scheme yet (__real_sem_post can imply "real-time" and not the 
correct opposite), but this is trivial to adapt. Personally, I would 
have preferred a clear separation where there are separate ways. One 
could then offer a mechanism to select the default mapping (e.g. 
sem_init = rt or non-rt by default). This would be useful for porting 
efforts with different degrees of rt and non-rt calls, or if you simply 
prefer the other way as currently is provided (like I do ;)).

No light without shadow. My first call of accuracy_rt with fusion CVS of 
June 5 gave this result:

Starting latency measurements at Sun Jun  5 13:15:32 2005
Sampling period = 2000 us
Hit ^C to get the results.
    test duration: 00:00:41
    nanosleep accuracy: jitter min = 1 us, jitter max = 7920 us
    semaphore wakeup: switch min = 4 us, switch max = 124459 us

(kernel was 2.6.11.10-adeos-r10)

Now, with fusion release 0.8 and kernel 2.6.11.12-adeos-r11c1, I even 
get a fatal lock-up after "Hit ^C ...". Normal fusion latency tests and 
other stuff seems to run flawlessly.

Any ideas where to search?

Another question: I somewhere read that it is legal to have both 
rtai_native and rtai_posix loaded at the same time, correct? But for 
dump users like me, is there a chance to prevent unloading the modules 
in the wrong order? I guess this reinstalls some handlers incorrectly 
and produces a nice oops. Only if it doesn't cost too much effort...

Jan


PS: Regarding signal support, a topic that also comes up again with the 
POSIX skin: Is there a chance to get adeos fixed with respect to 
ADEOS_SIGNAL_PROCESS? This would allow skins to provide signal 
forwarding (or dropping) handlers in primary context without the need to
switch to secondary first. Or am I overseeing some already applied fix?




More information about the Rtai mailing list