[lkml]   [2005]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RT patch acceptance
Lee Revell wrote:
> On Sat, 2005-05-28 at 13:53 +1000, Nick Piggin wrote:
>>Run RT programs in your RT kernel, and GP programs in your Linux
>>kernel. The only time one will have to cross into the other domain
>>is when they want to communicate with one another.
> And what about a multithreaded program with RT and non-RT threads?

Have to rewrite them.... Well, there are obviously none written for
Linux today, because it doesn't support hard-RT ;)

If you are talking about soft-RT, or things running on Linux today,
then sure they'll keep working. Even some or all of PREEMPT_RT may
be merged into the Linux guest too, for better soft-RT. I haven't
been arguing against that.

> No one ever said anything about hard RT IO, or making any syscalls hard
> RT.

Actually this is exactly what was being talked about. But note
that we're not specifically talking about PREEMPT_RT here, just
2 possible architectures that might achieve that.

> AFAIK this has never even come up during the PREEMPT_RT
> development. We just want our userspace code to be scheduled as soon as
> it's runnable. For the purposes of this entire thread, it's safe to
> assume that if the RT thread does make any syscalls, it knows exactly
> what it is doing, as in the JACK write() example.

I agree we'll never have a fully functional hard-RT Linux kernel.
But this thread hasn't been about whether or not the RT task knows
what it is doing (we assume it does), but the possibility of making
more parts of the kernel able to provide some RT guarantee (ie. so
said RT task *can* use more functionality).

Send instant messages to your online friends

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-05-28 06:47    [W:0.279 / U:2.932 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site