Re: Attempted summary of "RT patch acceptance" thread

[Bill Huey (hui) <bhuey@lnxw.com>]

On Sat, Jun 11, 2005 at 12:37:51AM +0200, Andrea Arcangeli wrote:
> Did you read Karim's answer at all?

Reverse to youe did you read message from the original thread at all ?
Karim supports this work and knows this is possible.

> Those RTOS don't have frenetic development in scheduler and all other

SCHED_FIFO isn't effected by it, nor is SCHED_RR. That's another hysterical
claim on your part.

> subsystems and they may be simpler as well, so perhaps you can disable
> L2 and L3 and measure all possible paths that kernel can take in
> invoking your rt code, but I doubt you're going to keep it up with linux
> development in demonstrating the worst case deadline in every possible
> hardware. Measuring all possible paths of a nanokernel is absolutely

Not an issue. Folks do it all of the time here. There's no hysteria
regarding this here. Single image kernel do it all of the time such as
Mach, QNX, LynxOS and friends. 

> RTOS may be fine for cellphones or other stuff where you may not even
> need hard-RT at all, but you just want the lowest possible latency, but
> I'd _never_ use it whenever I need a true deadline, since other more
> reliable solutions are possible without much more complexity.

Read the original thread. Folks have intention of doing more than you
realize at this point. Trivial strawman claims of provable verses
measured latencies are just stupid. The problem is not as wacked you
make it.

[cellphone commentary stripped]
 
> About the fact the kernel can crash, and a driver can corrupt memory,
> that's the difference between ruby and diamond.

Nanokernels crash as well from lack of memory protection. So what ?

You make too many assumptions in domain you have little experience in
and turn it into some assumed fatal argument about single image RT which
is far from reality and the true of the matter.

> I simply think RTOS is an awful solution to hard-RT, RTAI/rtlinux
> designs are much more reliable. There are certainly areas where RTOS is

LynxOS runs on HP printers for real time guarantees all of the time and
is good for general purpose usages as well. Folks use single image kernel
for RT guarantees even before the existence RTAI and RT Linux. Your history
is reversed here. People have been doing this for ages under a single image.

> acceptable, and this is where hard-RT isn't required and you simply want
> the lowest possible latency when invoking syscalls like alsa ioctls. But
> when alsa kernel code is out of the equation I'd never use RTOS to get
> the kernel out of the way.

Hard RT is required in audio. It's require in processing DSP data coming
from those cards. ioctl() paths are short and pretty much directly go to
the driver.

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/