lkml.org 
[lkml]   [2005]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RT patch acceptance
    Also, the u-kernel has been tried, MACH & Chorus, and even the real
    NT core, as opposed to the Win32 API skin, and has not worked well
    yet.

    James Bruce wrote:
    > Nick Piggin wrote:
    >
    >> But nobody has been able to say why a single kernel is better than a
    >> nanokernel.
    >
    >
    > I think it's a bit more like you haven't realized the answer when people
    > gave it, so let me try to be more clear. It's purely a matter of effort
    > - in general it's far easier to write one process than two communicating
    > processes. As far as APIs, with a single-kernel approach, an RT
    > programmer just has to restrict the program to calling APIs known to be
    > RT-safe (compare with MT-safe programming). In a split-kernel approach,
    > the programmer has to write RT-kernel support for the APIs he wants to
    > use (or beg for them to be written). Most programmers would much rather
    > limit API usage than implement new kernel support themselves.
    >
    > A very common RT app pattern is to do a bunch of non-RT stuff, then
    > enter an RT loop. For an example from my work, a robot control program
    > starts by reading a bunch of configuration files before it starts doing
    > anything requiring deadlines, then enters the RT control loop. Having
    > to read all the configuration in a separate program and then marshall
    > the data over to an RT-only process via file descriptors is quite a bit
    > more effort. I guess some free RT-nanokernels might/could support
    > non-RT to RT process migration, or better messaging, but there's
    > additional programming effort (and overhead) that wasn't there before.
    > In general an app may enter and exit RT sections several times, which
    > really makes a split-kernel approach less than ideal.
    >
    > An easy way to visualize the difference in programming effort for the
    > two approaches is to take your favorite threaded program and turn it
    > into one with separate processes that only communicate via pipes. You
    > can *always* do this, its just very much more painful to develop and
    > maintain. Your stance of "nobody can prove why a split-kernel won't
    > work" is equivalent to saying "we don't ever really need threads, since
    > processes suffice". That's true, but only in the same way that I don't
    > need a compilier or a pre-existing operating system to write an
    > application.
    >
    > - Jim Bruce
    > -
    > 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/
    >
    >

    --
    mit freundlichen Grüßen, Brian.

    Dr. Brian O'Mahoney
    Mobile +41 (0)79 334 8035 Email: omb@bluewin.ch
    Bleicherstrasse 25, CH-8953 Dietikon, Switzerland
    PGP Key fingerprint = 33 41 A2 DE 35 7C CE 5D F5 14 39 C9 6D 38 56 D5
    -
    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-29 14:28    [W:0.034 / U:91.368 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site