lkml.org 
[lkml]   [2005]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RT patch acceptance

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

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@opersys.com || 1-866-677-4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-06-01 03:12    [W:0.193 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site