Re: Attempted summary of "RT patch acceptance" thread

[Karim Yaghmour <karim@opersys.com>]

Daniel Walker wrote:
> I think this is mistake. Projects that create separation like this are
> begging for the community to reject them. I see this as a design for
> one, instead of design for many mistake. From what I've seen, a project
> would want to do as much clean integration as possible.

I understand what you're saying, but based on the feedback
PREEMPT_RT has gotten up until now, and now outright suggestions
that the debate is not even relevant to the LKML, I think that
some people are trying to give those interested a hint: integration
with mainline code is NOT on the agenda.

Some may want to continue trying to force-feed mainstream
maintainers. I can't stop anyone from trying, that's for sure.
However, I think what I'm suggesting is a reasonable compromise:
mainstream maintainers don't need to care about RT on a day-to-
day basis and the RT folks get to be part of mainline.

That said, please make sure you've carefully read through what
I suggest. I'm not saying that everything inside the kernel needs
to be duplicated. I'm saying that what add-ons are should be
separate. For example, like I was first saying, headers in
include/linux-hrt would point back to include/linux-srt where
appropriate.

And like I said earlier, this suggestion would need to be refined.

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/