[fusion] userspace POSIX skin
jan.kiszka at web.de
Thu Jun 16 21:35:08 CEST 2005
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 126.96.36.199-adeos-r10)
Now, with fusion release 0.8 and kernel 188.8.131.52-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...
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