Re: RT patch acceptance

[Nick Piggin <nickpiggin@yahoo.com.au>]

Nick Piggin wrote:
> Bill Huey (hui) wrote:

> > Uh, not really. Have you looked at the patch or are you inserting
> > hysteria in the discussion again ? :) Sounds like hysteria.
>
> OK, I'll start small. What have you done with the tasklist lock?
> How did you make signal delivery time deterministic?
>
> How about fork/clone? Or don't those need to be realtime? What
> exactly _do_ you need to be realtime? I'm not asking rhetorical
> questions here.

Let me ask another question while you're thinking about that.
Note, this is a *specific* question that can easily be answered
without waffling about XFS or telling me to start writing RT
media apps, or accusing me of spreading hysteria...

OK:

I think it has been conceeded that a realtime Linux kernel
cannot be enabled by default because of prohibitive overhead,
right? I think this is even the case for PREEMPT_RT, which is
not hard-RT. (Correct me if I'm wrong).

Suppose you had a system where you need some RT operations,
but cannot tolerate such overhead for general purpose
performance processing.

So by definition you have excluded a single kernel approach.
A nanokernel is not clearly excluded. In fact, maybe it is
possible to run the Linux image with little overhead? Maybe
almost none with the right CPU hardware? (correct me...)

If you get to here without correcting me, my question is:
does such an application exist? Silly example is a cell
phone + JVM, but something really interrupt heavy (and
maybe SMP as well) might be better to cripple PREEMPT_RT.

Thanks. I can think of some other specific questions too,
when you've addressed these.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/