Re: RT patch acceptance

Nick Piggin
2005-05-30T14:21:35Z

James Bruce wrote:
> Nick Piggin wrote:
>
>> Sorry no, nobody answered me. What I did realize was that there
>> was a lot of noise nothing really got resolved.
>
>

[snip lots of stuff]

Sorry James, we were talking about hard realtime. Read the thread.
What's more, I don't think you understand how a nanokernel solution
would work, nor have much idea about the complexity of implementing
it in Linux (although that could have been a result of your thinking
that we weren't talking about hard-rt).

And my questions for which I got no answer were things like
"why is a single kernel superior to a nanokernel for hard-RT?",
"what deterministic services would a hard-RT Linux need to provide?"

So most of what you said is irrelevant, but I'll pick out a few bits.

[snip]

> Yes, you "shoot holes" by bringing up examples such as fork/exec and
> other things RT apps would almost never do while expecting to meet

No, that wasn't part of any of my hole shooting. I asked what operations
need to be realtime and have not had an answer. fork/exec was "prompting".

> deadlines. Then at the same time, when someone describes what an RT
> application typically does do, you claim how simple and trivial it all
> is, and without knowing any of the details tell them that it'd be easy
> to split it into separate processes.

Err, your example was "reading a configuration file". Not exactly
rocket science my good man.

> Please explain how a split-kernel
> method supports a continuous progression from soft-realtime to
> hard-realtime, where each set of API calls has associated latency
> effects that may or may not be tolerable for a given application. That's
> the problem space, and I can guarantee applications exist all along that
> progression, and many don't fall cleanly into one side or the other.
>

You say this like you have a confabulous solution ready to plonk
into the Linux kernel.

But it is not up to me to point out why one way is better than the
other because I am not asking to have anything merged (not saying
*you* are either, I joined this thread by asking an open ended
question).

>> I hate to say but I find this almost dishonest considering
>> assertions like "obviously superior" are being thrown around,
>> along with such fine explanations as "start writing realtime apps
>> and you'll find out".
>
>
> I said neither, why don't you take it up with the authors of those
> comments. Btw, Mach was extended to do RT in a project called RT-Mach.
> Since you like that approach so much, maybe you should ask yourself why
> it failed. You could also think about why the Jack people aren't using
> something like RTAI with its nanokernel approach. It's certainly not
> because the people working on those systems are ignorant.
>

I have a better idea. I won't read up on any of that, and I will go
and do my own thing and stop wasting my time on this thread. Then
whoever wants to start putting hard realtime functionality into Linux
can *tell* me why nanokernels failed, OK? Let's end the discussion
until then. It is going nowhere.

Send instant messages to your online friends http://au.messenger.yahoo.com