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 || [email protected] || 1-866-677-4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
