lkml.org 
[lkml]   [2005]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RT patch acceptance

    Ingo Molnar wrote:
    > just to make sure, by "much more complicated" are you referring to the
    > PREEMPT_RT feature? Right now PREEMPT_RT consists of 8000 new lines of
    > code (of which 2000 is debugging code) and 2000 lines of modified kernel
    > code. One of the primary goals i had was to keep it simple and robust.

    I'm refering to the complexity of the behavior. Turning interrupts to
    threads and spinlocks to mutexes makes vanilla Linux's behavior much
    more complicated than it already is. But before a bunch of mouth-foaming
    rugby players tackle me to the ground, please keep in mind that this is
    my appreciation of things. Others have claimed that they are perfectly
    fine with this ...

    > That's more than 3 times smaller than UML and it's almost an order of
    > magnitude smaller than a nanokernel codebase i just checked, and it
    > boots/works on just about everything where the stock Linux kernel boots.
    > I challenge you to write a nanokernel/hypervisor with a comparable
    > feature-set in that many lines of code.

    No challenge needed, I'm not refering to codebase. No to mention that I'm
    not even going to get near claiming knowing the kernel's guts anywhere
    as much as you do :)

    Here's running the risk of comparing apples to oranges:
    $ ll adeos-linux-2.6.11-i386-r10c3.patch realtime-preempt-2.6.12-rc4-V0.7.47-07
    -rw-rw-r-- 1 karim karim 195105 May 24 10:19 adeos-linux-2.6.11-i386-r10c3.patch
    -rw-rw-r-- 1 karim karim 610509 May 24 00:14 realtime-preempt-2.6.12-rc4-V0.7.47-07

    > anyway, as always, the devil is in the details. I certainly dont suggest
    > that nanokernels/hypervisors are not nice (to the contrary!), or that
    > all component technologies of the -RT patchset will be accepted into
    > Linux. PREEMPT_RT started out as an experiment to reduce scheduling
    > latencies within the constraints of the Linux kernel. It is not an
    > all-or-nothing feature, it's more of a collection of incremental
    > patches. It is one, nonexclusive way of doing things.

    Here's from a previous posting back in october:
    > development pace. Let's face it, no self-respecting effort that has
    > ever labeled itself as wanting to provide "hard real-time Linux"
    > has been active on the LKML on the same level as Ingo (though many
    > have concentrated a lot of effort and talent on other lists.)

    Clearly I recognize the work you have accomplished, and you are correct
    in stating that the approach is nonexclusive. If the patch does indeed
    make it into the kernel, then so be it. It's worth considering though
    that there are other methods which can provide hard-rt without increasing
    the kernel's complexity even when enabled; the most basic of which would
    be turning the interrupt-handling/disable to function pointers. At the
    next level, you could have something like the interrupt pipeline from
    adeos on top (possibly as a loadable module), and at a third level you
    could have something like RTAI/fusion (as additional loadable modules) ...

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

    \
     
     \ /
      Last update: 2005-05-24 18:19    [W:2.949 / U:0.632 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site