Re: RT patch acceptance

From: hui (bhuey_at_lnxw.com)
Date: 05/31/05

  • Next message: Parag Warudkar: "Re: RT patch breaks X86_64 build" 
    Date:	Mon, 30 May 2005 19:09:57 -0700
To: Nick Piggin <nickpiggin@yahoo.com.au>

    On Tue, May 31, 2005 at 11:21:49AM +1000, Nick Piggin wrote:
    > Bill Huey (hui) wrote:
    > >That's an RT begineer's question. You have to at least be up to speed
    > >in that one to have the conversation at hand and folks have discussed
    > >this repeatedly. It's not our end that failing and clearly you not
    > >understanding this only reenforces this point..
    ...
    > Bill, you can belittle me to your heart's content. It really
    > doesn't bother me in the slightest.

    It's not belittling, but venting my frustration at you not
    understanding what I'm saying with an escalating ramp of force, jerk. :)

    > Whenever you or anyone else try to complicate the Linux kernel
    > with hard-RT stuff, I'm going to ask exactly the same questions
    > because I don't think you know how a nanokernel solution would
    > work, or even what kind of services a hard-RT Linux would need
    > to provide.

    Well, depends on the scope of the thing we're talking about. If
    you mean pervasively throughout the kernel for every system, then
    no at first if ever. If you mean for what the nanokernels are
    commonly used for then, yes. We're quite close to that already
    to be hard real time if you just trust eyeballing the core kernel
    code. The remaining problems have been pretty much partitioned to
    fringe file system logic, some networking code and things outside
    of the core kernel (kernel/ generally). They'll have to be surveyed
    and hammered manually. All other points, if you trust eyeballing,
    should run within an interrupt plus a thread to enable if assuming
    you're not runing within an interrupt/preempt off section.

    Theorem proven kernels are another matter altogether, but in all
    practicality we're very close to hard real time. Calling it soft
    real time isn't exactly accurate too, but the thrust to get
    theorem proven RT kernels recently has made the definitions more
    rigid in this discussion, probably overly so. Linux will probably
    never be submitted to any prover to do attain that. Very few,
    (only one product of ours that I know of LynxOS 178) have taking
    on that provability track. This is a highly competitive field.

    There's many things being discussed. The original examples I've
    given probably clouded things for you when I ment it to be clear
    problem by setting the most extreme examples. Really, the problems
    are more complicated than that and really are quite varied. But
    the first step is to get at CPU resources in a deterministic
    manner at first, the rest, in what ever form, comes later.

    Food time :)

    bill

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

  • Next message: Parag Warudkar: "Re: RT patch breaks X86_64 build"

    Relevant Pages

    • Re: Unix runs faster, maybe
      ... A kernel which can do hard real time is at the top of the list. ... I didn't think VMS was hard realtime. ...
      (comp.os.vms)
    • Re: Newbie Question About Device Drivers
      ... I guess we are trying to achieve a more "Real Time" operating system. ... in the kernel you have access to the ... >if you can achieve what you want in user space, it is probably better to do ...
      (microsoft.public.development.device.drivers)
    • JAD and AppArmor problem
      ... during boot up that I can not modify, add or delete any AppArmor profiles. ... Has anybody booted to the rt kernel and got AppArmor ... jackd runs with real time capabilities enabled. ...
      (alt.os.linux.suse)
    • RE: Intel marginalizing Itanium even faster than expected?
      ... Behalf Of Bill Gunshannon ... Once you start twiddling bits in the kernel on your own, ... how many companies want to risk not being able to point the ... easier to replace a BSD guru than an HO-UX or VMS guru. ...
      (comp.os.vms)
    • Re: Unix runs faster, maybe
      ... A kernel which can do hard real time is at the top of the list. ... Linus felt that the issues brought up by real time should be handled ... I don't ever expect real time Linux to keep up with pure real time OS ...
      (comp.os.vms)