Re: Attempted summary of "RT patch acceptance" thread

[Karim Yaghmour <karim@opersys.com>]

Daniel Walker wrote:
> I wouldn't work on RT if mainline integration wasn't on the agenda. 

Mainline integration IS what I'm talking about. It's just not done
the same way.

> There is going to be positive , and negative discussion on this. I think
> in the end the maintainers (Linus, and Andrew) don't want "people" to
> get a patch or modification from the outside. It's best if the community
> is not separated .. If you make a clean integration , and people want
> what you are doing, there is no reason for it to be rejected.

I'm not suggesting the separation of the community, I'm suggesting
a strategy of integration based on the fact that a large portion of
kernel contributors don't necessarily care about RT, and most don't
want to care about it in their day-to-day work (though I think most
would care that Linux could have an additional spade down its
sleeve, and would certainly try to help in as much they can from
time to time.)

I'm not suggesting asking "people" to get patches from the outside.
What I'm saying is that those developing mainstream code shouldn't
need to worry about anything real-time, including modifications to
locking primitives in headers (be they defined out or in).

In essence, what you ask can only hold if all kernel developers
intend for Linux to become QNX. Clearly this isn't going to happen.
Whatever changes are made to such core functionality as locking
primitives and interrupt handling can hardly be "transparent"
simply by wrapping #ifdef CONFIG_X around it in mainstream headers.

>From my point of view, determinism and best overall performance are
conflicting goals. Having separate derectories for something as
fundamentally different from best overall performance as determinism
is not too much to ask.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546