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 || [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]
