Messages in this thread | | | Date | Mon, 13 Jun 2005 07:40:22 -0700 | From | "Paul E. McKenney" <> | Subject | Re: Attempted summary of "RT patch acceptance" thread |
| |
On Sun, Jun 12, 2005 at 09:35:15PM -0400, Karim Yaghmour wrote: > > 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.
OK... Then the idea is to dynamically redirect the symbolic link to include/linux-srt or include/linux-srt that you mentioned in your previous email, or is the symlink serving some other purpose?
> > 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 your focus is on system calls that can have totally separate realtime and non-realtime implementations? Or am I missing some trick here?
> > 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.
Single kernel, multiple implementations for some syscalls, more or less, anyway.
> 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.
My guess is that there are enough people in the PREEMPT_RT camp that it might not make sense to ascribe a single point of view to them ;-)
How are you and Kristian looking to benchmark/compare the various combinations you call out above? Seems like one would have to look at more than straight scheduling/interrupt latency to make a reasonable comparison.
Thanx, Paul - 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/
| |