Re: Attempted summary of "RT patch acceptance" thread

[Karim Yaghmour <karim@opersys.com>]

Paul E. McKenney wrote:
> This could potentially address the need for version-synchronization
> between RTAI-Fusion and the Linux kernel.  Would you really want two
> separate builds, or is there some reasonable way of producing a single
> kernel binary that has both?  And if there is some reasonable way of
> doing this, is it the right thing to do?

No, single build is what I'm looking for. Nothing precludes the
fusion parts from being built during the same kernel build ...
as modules. If you don't load 'em, you don't need to worry about
'em.

> The single-binary approach could potentially reduce the
> dual-OS-administration load associated with RTAI-Fusion.  However,
> handling all the interactions between the deterministic and
> non-deterministic system calls could get hairy.  No big deal for
> scheduling primitives, but things could get interesting for I/O and
> networking protocols.

Again, if you don't load 'em, you don't get 'em. If you use it
and it's broken, then you're doing rt and you need to sync up
with the maintainer. Nothing different here from the standard
run of the mill "I'm using subsystem X and it doesn't work"
posting to LKML.

> So, one can use the following types of combination:
> 
> o	single source tree, multiple kernels (which is what I now
> 	think that you are getting at above).
> 
> o	straight merge, as between PREEMPT and PREEMPT_RT.
> 
> o	single kernel, multiple syscall implementations for
> 	some syscalls (deterministic vs. non-deterministic).
> 
> o	side-by-side combination, as with dual-OS/dual-core and
> 	pretty much any other approach.

I'm not sure how you'd fit what I'm trying to suggest above, but
let me rephrase it with the above in mind:

What I'm suggesting is that all rt components be included, but
in separate directories within mainline. That may or may not
mean additional schedulers/services. In the case where the
new layout would include both PREEMPT_RT and fusion, what
we'd get is that the user would have access to these configs:
- Plain Linux, no PREEMPT_RT, no ipipe, no fusion.
- Linux with PREEMPT_RT, no fusion: ints are threaded and locks
  are mutexes like now (however without the code intrusiveness
  given the use of separate directories.) May or may not include
  ipipe.
- Linux with fusion, no PREEMPT_RT: the fusion modules are built
  and installed with the rest of the modules. ipipe must be
  enabled.
- Linux with fusion and PREEMPT_RT: combination of the previous
  two.
- Linux with ipipe, no fusion or PREEMPT_RT: the soft-cli stuff
  is built into the kernel and loaded drivers can get
  deterministic response times, but there are no fancy rt
  services offered to anyone.

Practically, linux/hard-rt/ would contain both the code for
PREEMPT_RT and the code for fusion. The actual layout in that
directory would still need to be detailed, but the desired
effect is that both PREEMPT_RT and fusion share as much code
as possible.

Hope this clarifies what I'm suggesting a little bit more. Of
course, all this would need to be rehashed a number of times,
and most importantly, the PREEMPT_RT folks and the fusion
effort would need to agree to join forces. From the fusion
POV, it's clear that the door is open for collaboration. As
proof, Philippe has been publishing combo patches with Adeos
and PREEMPT_RT for some time. I can't speak for the PREEMPT_RT
POV, though. I might be mistaken, but it seems that the feedback
I've seen from some PREEMPT_RT backers does seem to indicate
some openess. We'll see how things go.

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