[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

    Paul E. McKenney wrote:
    > 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?

    What I'm suggesting is that rt patches shouldn't touch the existing
    codebase. Instead, functionality having to do with rt should be
    integrated in separate directories, and depending the way you
    configure the kernel, include/linux would point to either
    include/linux-srt or include/linux-hrt, much like include/asm
    points to one of inclux/asm-*.

    > So your focus is on system calls that can have totally separate
    > realtime and non-realtime implementations? Or am I missing some
    > trick here?

    There's no trick. It's just a layout thing. Hope the above
    explains what I'm trying to say.

    > 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.

    I'm not sure that benchmarking would be relevant. This is just a
    integration/layout/configuration/build suggestion. I don't think
    that this organization will change anything to the benchmark

    Author, Speaker, Developer, Consultant
    Pushing Embedded and Real-Time Linux Systems Beyond the Limits || || 1-866-677-4546
    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 21:43    [W:0.020 / U:6.252 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site