lkml.org 
[lkml]   [2005]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: RT patch acceptance
    From
    Date
    On Tue, 2005-05-31 at 14:09 +0200, Esben Nielsen wrote:
    > On Tue, 31 May 2005, James Bruce wrote:

    > > It is only better in that if you need provable hard-RT *right now*, then
    > > you have to use a nanokernel.
    >
    > What do you mean by "provable"? Security critical? Forget about
    > nanokernels then. The WHOLE system has to be validated. If you want to a
    > system good enough to put (a lot of) money on it: Test, test, test.

    Interesting. I use to work for Martin Mariette in the early 90s testing
    modules for aircraft engine controls. The code was about ten years old,
    and that is because it was going under ten years of testing. The
    operating system was custom made since at the time there were no
    commercially available (that I knew) RTOS that could go under the
    scrutiny of the Military Specs.

    Later, while working at Lockheed, we had WindRiver over and they would
    only give a small broken down (basically all features removed) OS that
    Lockheed would be responsible for testing.

    When someone mentions Hard-RT, this is what I think about. These are
    the RTOS that control the airplanes that people fly in. If something
    were to go wrong, people will die.

    I no longer deal with that type of RT, now I still work with
    applications that run on aircraft, but would not have the plane crash if
    something was to go wrong. The system still had to be of a softer-RT to
    give the required response, usually navigational. This is someplace
    that a Linux with -RT or a nano kernel can go. The -RT patch may be
    nicer since some applications are first written generically, and then
    later need to become -RT for some reason or another. With the nano
    approach this may take more effort. But at the moment, I'm working to
    get -RT with some extra features for other things, but this is what I've
    heard from others.

    > I can't see it would be easier prove that a nano-kernel with various
    > needed mutex and queuing mechanism works correct than it is to prove that
    > the Linux scheduler with mutex and queueing mechanisms works correctly.
    > Both systems does the same thing and is most likely based on the same
    > principles!

    Since the nano-kernel would be much smaller than the kernel, you don't
    need to worry about a bad design as much that can cause a problem. I
    don't know how easy it would be to separate all the paths that an RT
    task uses, and make sure that there's not a lock that an RT task takes
    that isn't taken someplace else that a non RT task can take for a long
    time (even with PI). It's just that the kernel is so big to find
    everything. This isn't impossible, but very difficult to check out.

    -- Steve

    -
    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-31 20:51    [W:3.169 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site