Re: RT patch acceptance

[Nick Piggin]

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 
-
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/