Re: RT patch acceptance

[hui]

On Tue, May 31, 2005 at 07:33:38PM +1000, Nick Piggin wrote:
> James Bruce wrote:
> >claims he's made, but I think a lot of people have read his posts too 
> >quickly and misinterpreted what he's claiming for the current patch. 
> >This includes people on both sides of the fence.  He's also been silent 
> >for much of this discussion as its gotten out of hand, showing he's 
> >clearly wiser than all of us.
> 
> I have never been in any doubt as to the specific claims I have
> made. I continually have been talking about hard realtime from
> start to finish, and it appears that everyone now agrees with me
> that for hard-RT, a nanokernel solution is better or at least
> not obviously worse at this stage.

No, not true. That's large a myth created by dual kernel folks. The
scheduling and interrupt paths are highly optimized in Linux it's
unlikely that any other OS can really make it significantly better
in this area since the paths are branch hinted and cache sensitive.
This core logic is pretty much similar across most RTOSes.

> Ingo actually of course has been completely rational and honest
> the whole time - he actually emailed me to basically say "there
> will be pros and cons of both, and until things develop further
> I'm not completely sure".

There will be pro and cons of both, but in the end single kernel
aspects will win because app programmability issues. The dual kernel
boundary only exists because nobody took on the task of full kernel
preemptibility because of the broad amount of knowledge needed to
get the lock ordering correct as well as other concurrent conversions.

It's done now and dual kernel will have less of a strangle hold on
RT development in Linux. This will be inevitable as the technology
propagates.

> Which I was pretty satisfied with. Then along came the lynch mob.

The lynch mob is right. They have first hand experience with this
kind of work and understand the associated problem with this kind
of software development. This isn't some piecewise kernel hack that's
an easy tack on to the kernel, but a fundamentally different way
of looking at things. Understanding the concepts is mandatory here.

That's something that you're still not willing to learn which makes
discussions with you on the subject useless and pisses off the rest
of us.

bill

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