Re: Attempted summary of "RT patch acceptance" thread

[Andrea Arcangeli <andrea@suse.de>]

On Fri, Jun 10, 2005 at 03:19:14PM -0700, Bill Huey wrote:
> managable problem. Again, this a problem for all RTOS system and their
> supporting drivers as well since they often come from BSD open source
> community.

Did you read Karim's answer at all?

Those RTOS don't have frenetic development in scheduler and all other
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
trivial in comparison cause there are no different paths, so it's very
easy to give a worst case deadline to the RTAI/rtlinux designs, while it
sounds a total pain for preempt-RT, even after the local_irq_disable
issue is fixed (which is feasible as Daniel seems to have implemented
already).

metal hard solutions are fine where having an exact deadline isn't
required, or in places where missing the deadline results in a crashed
cellphone (even if I really hate it if my cellphone crashes, and yes
even the linux cellphone crashes by doing a cp /dev/sda /dev/null, the
usbstorage thingy has some problem in accessing the partition table of
the internal flash), but again if they would have picked a RTOS for the
project I linked on linuxdevices.com that has to react in 50usec, I
think they would have done a mistake when ruby-hard solutions like
RTAI/rtlinux are available on linux. So kudos to them for their IMHO
best correct choice of RT design.

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.

But this is me and my focus is on projects like the one quoted on
linuxdevices, cellphones may not even need hard-RT at all since I doubt
anybody would offload the gsm compression to the main linux cpu with the
risk of doing a buffer overflow during decompression and crashing
stations. You're free to use a metal-hard solution for problems that
requires ruby-hard, but I think that's very wrong choice after you're
aware it's not possible to math demonstrate a worst case latency with
metal-hard solutions.

About the fact the kernel can crash, and a driver can corrupt memory,
that's the difference between ruby and diamond.

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