> > Well, I personally would rather see that nobody ever needed RTlinux at
> > all. I think hard realtime is a waste of time, myself, and
>
> The need for hard real-time comes when you have real-world requirements that
> require absolute timing garantees with 100% reliability.
If you hadn't snipped the rest of the email, you'd have seen that I agree:
_if_ there are truly hard guarantee requirements, RTLinux is the way to
go.
The number of problems that really need RT-linux is practically zero for
normal uses. This is, btw, why I've never applied the RTLinux patches to
the standard kernel tree. My personal opinion is that the RTLinux patches
should _not_ be available by default, so that only people who really need
the functionality start using it.
Having non-hard-RT users start using the RTLinux functionality would be a
disaster, in my opinion. The programming-interfaces are much more
cumbersome, and the ways of making the system lock up hard are many and
varied.
If you do a computer-controlled radiation-dose machine for treating
patients, and the latency guarantees have to be in the sub-100ms range,
THEN you should use RTLinux.
If you're doing just audio that needs approximately 1% fo the CPU
resources, and you have to use hard-realtime, the system needs work. Using
RTLinux is a way of saying "oh, we can't fix this properly@.
NOTE: I'm fully aware of the fact that Linux needs improvment in this
area. I've tried to explain that my beef with the low-latency patches has
never been that I don't believe it is a worthy goal. It's just that I also
firmly believe that there are right ways of doing this. Without ugly
patches that add random stuff to random places.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/