lkml.org 
[lkml]   [2005]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: RT patch acceptance
From
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/

\
 
 \ /
  Last update: 2005-05-31 04:09    [W:0.477 / U:0.796 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site