Re: Attempted summary of "RT patch acceptance" thread

[Karim Yaghmour <karim@opersys.com>]

Paul E. McKenney wrote:
> The big thing that I learned in reviewing the thread and in doing the
> writeup is that there are a lot of different things that a realtime app
> might want from a OS and from the hardware.  It seems to me that we
> probably cannot do a simple linear ranking of the approaches -- some
> will be better at one aspect, others will be better at another.

During the earlier thread, I did suggest a third option which I think
could help integrate both PREEMPT_RT and the interrupt pipeline in
Adeos and RTAI-fusion _without_ impacting on the rest of the kernel
code. However, I haven't received any feedback whatsoever in that
regard. So here it is again. Given how much discussion space is taken
on "concepts", it may be worth entertaining a third option.

> <alternate proposal>
> Much like there is nothing precluding PREEMPT_RT to co-exist with
> the nanokernel approach (on which RTAI is based), it could be suggested
> the adding of a linux/hard-rt directory containing the (re?)implementation
> of services/abstractions required for hard-rt applications. You still
> get a single tree, but there's then a clear separation at many levels,
> including maintainership. As such, much of what RTAI-fusion is currently
> doing could find itself in linux/hard-rt. For example, RTAI-fusion
> transparently provides a hard-rt deterministic nanosleep(). This and
> other such replacements for kernel/*.c would live in hard-rt/ with
> no disturbance to the rest of the tree. In the same way, include/linux
> could be a symbolic link to either include/linux-hrt or include/linux-srt,
> with headers in include/linux-hrt referring back to include/linux-srt
> where appropriate. Again, zero cost for mainstream maintainers. If the
> hard-rt stuff breaks, only the rt folks get the pain. Note that I'm not
> suggesting creating duplicates like this for all directories. In fact,
> most of what's in arch/* and drivers/* would remain unchanged, and
> where appropriate, hard-rt/* and include/linux-hrt should reuse as much
> of what already exists as possible.
> 
> Sure, the hard-rt part wouldn't have all the bells and whistles of the
> mainstream part, but that's what we're going to have anyway if
> PREEMPT_RT is included (as is clearly acknowledged elsewhere in this
> thread by those backing it), unless there's a general consensus amongst
> all subsystem maintainers that Linux should become QNX-like ... which,
> to the best of my reading of this thread, most are not interested in.
> 
> The above suggestion doesn't solve the two-app vs. one-app dilemma, but
> it takes away the "oh, horror, we need to maintain two separate kernel
> trees for our application development" from those against the nanokernel
> approach _without_ imposing additional burden on mainstream maintainers.
> </alternate proposal>

Let me clarify what I say above to make it clear that linux/hard-rt
and include/linux-hrt/ could/would include a merged PREEMPT_RT, adeos, and
rtai-fusion. The combo patch put together by Philippe (which includes both
PREEMPT_RT and adeos) is already a good start in that direction. Like we
said earlier, both methods are not mutually exclusive.

Note that my purpose by posting this proposal is to invite further
discussion as to what is the best way to integrate any real-time approach
to the existing kernel structure. What approach eventually makes it into
this structure, whether it be PREEMPT_RT, Adeos, fusion, a combination of
these, or something entirely different, is not something I attempt to
resolve here. As it currently stands, for PREEMPT_RT at least, the
intrusiveness of the patch onto the mainstream code is something that
seems to make a lot of people uneasy.

Like I said earlier:
> ... so here goes, it's just an idea I'm throwing in the lion pit ...
> it clearly would require much more work and input ... so devour, tear,
> and crush at will ...

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