ANNOUNCE: fusion 0.1

[Herman Bruyninckx]

On Sun, 20 Jun 2004, Philippe Gerum wrote:

>> [...]
>>> o In parallel, I'm working on allowing the user-space programs that are
>>> registered as fusion-enabled applications
>>
>> What exactly does this mean: "be registered as fusion-enabled
>> application"? How does a user space program do this? (I guess it's
>> nothing more than the RTAI make_hard_realtime()...?)
>
> A bit more in fact. There is a special extended syscall available to the
> Linux apps when fusion is active which creates a RTAI "shadow thread"
> for it; this is not a buddy, but rather a placeholder that allows the
> said task to be also scheduled by the real-time nucleus.
Does application writers have to invoke this "extended syscall"
themselves?

[...]
> In the old times, we
> used to have to partition the work by putting some stuff in kernel space
> for high determinism, and leave other non time-critical portions of the
> application in user-space with some communication path between them,
> like FIFOs. Now, with respect to the constraints you have in terms of
> latency, you may well use portions of the NPTL for your real-time
> support if, say < 200us _guaranteed_ latency, is good enough for your
> application. If this is not enough, then you could still put your app in
> kernel space, since skins, as modules, also export their interface to
> other modules there, or in user-space ala LXRT provided you don't
> re-enter the Linux kernel and only rely on the syscalls controlled by
> the nucleus.

Waw, this seem to have the danger to become even more confusing for RTAI
users than (NEW)LXRT was...  I hope we come up with more
self-explanatory names than "LXRT" and "fusion-enabled"...

[... about NPTL...]
> My current use currently covers mutexes, condvars and semaphores without
> any pathological cases detected; 
Okay, that's what I'd expected too.

> so there is hope. The timer stuff is
> special, since if we want the user to think it is still using the
> standard POSIX support, we have to redirect these Linux syscalls to RTAI
> transparently, because only RTAI is able to provide the desired level of
> accuracy (e.g. sub-HZ timing) and latency (both interrupt and dispatch).

How about the fact that high resolution POSIX timers are now part of the
vanilla Linux kernel?

Thanks for your extensive answers! :-)

Herman

-- 
   K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480