Re: Attempted summary of "RT patch acceptance" thread

[Eugeny S. Mints]

Karim Yaghmour wrote:
> 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 
I would suggest that "don't want to care about it" already led and could 
lead to more bugs similar to the bugs discovered due to RT 
enchancements. But the bottom line here is that these bugs are almost 
always bugs in SMP kernel as well about which each kernel developer have 
to worry about.
> (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.
Do you hardly working on the kernel patched with RT patch in other 
configurations than PREEMPT_RT? But I'm working and can;t report any 
outstanding issues/degradation. These changes _are_ "transperent" due to 
preemtp modes configurability. So what do you have behind "can hardly be 
"transparent" simply by wrapping #ifdef CONFIG_X around it"?
> > 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.
configurability of the kernel gives you possibily to choose what you 
want in your custom case. Source code organization is a matter of 
whatever else (readability, complexity, separation of completely 
different functionality (but this is not this case), desire for 
community acceptance, etc) but not that determinism and best overall 
performance are conflicting goals. Why don;t you object against SMP 
though it definitly could conflict with goals of desktop kernel 
configurations?

	Eugeny
> Karim


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