[lkml]   [2005]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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

    Thanx, Paul
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-06-13 16:44    [W:0.035 / U:38.936 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site