Re: RT patch acceptance

[Paul E. McKenney]

On Tue, May 31, 2005 at 09:14:59PM -0400, Karim Yaghmour wrote:
> 
> [ removed a lot of interesting stuff ... ]
> 
> Andrea Arcangeli wrote:
> > The point where preempt-RT enters the hard-RT equation, is only if you need
> > syscall execution in realtime (like audio, but audio doesn't need
> > hard-RT, so preempt-RT can only do good from an audio standpoint, it
> > makes perfect sense that jack is used as argument for preempt-RT). If
> > you need syscalls with hard-RT, the whole thing gets an order of
> > magnitude more complicated and software becomes involved anyways, so
> > then one can just hope that preempt-RT will get everything right and
> > that somebody will demonstrate it.
> 
> Please have a look at RTAI-fusion. It provides deterministic
> replacements for rt-able syscalls _transparently_ to STANDARD
> Linux applications. For example, an unmodified Linux application
> can get a deterministic nanosleep() via RTAI-fusion. The way
> this works, is that rtai-fusion catches the syscalls prior to
> them reaching Linux. So even the syscall thing isn't really a
> limitation for RTAI anymore.

I -completely- misinterpreted

	http://www.fdn.fr/~brouchou/rtai/rtai-doc-prj/rtai-fusion.html

on first reading some months ago.  It looks much more interesting
on second reading.  It does not have the degree of isolation that
the pure double-kernel approaches do, since as the paper states,
Linux can "hide" tasks that are waking up from I/O events.
However, it does appear to provide a unified user-level environment.

I will add it to my list of approaches to realtime in Linux!

					Thanx, Paul

> Philippe would be in a better position to elaborate, but that's
> the essentials of it.
> 
> Karim
> -- 
> Author, Speaker, Developer, Consultant
> Pushing Embedded and Real-Time Linux Systems Beyond the Limits
> http://www.opersys.com || karim@xxxxxxxxxxx || 1-866-677-4546
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/