Montavista's "Open Source Real-Time Linux Project" again

Jan Kiszka jan.kiszka at
Fri Oct 15 01:12:37 CEST 2004

Gilles Chanteperdrix wrote:
> Karim Yaghmour wrote:
>  > (...)
>  > to qualify as hard-rt, it must be demonstrated mathematically/
>  > algorithmically that a system is truly deterministic. In order to meet
>  > such criteria, the proponents of these preemption-on-steriod patches
>  > would need to show that _ALL_ software written for Linux in the past
>  > is now somehow compatible with hard-rt.
> I do not see where this argument lead us: the same is true for RTAI, and
> I suspect many people are using RTAI without having done a mathematical
> proof of the correctness of its code. People generally assume that their
> system is not so strange that running it under heavy load for a few
> hours (or days) will not let the hot spots appear. This may look
> frightening for people leaving in the dream world of theory, but
> concretely, it does not work that bad, and this is actually the approach
> used for many "industrial" products, like medicine, cars, genetically
> modified food, etc...

In fact, this is how things really work. But this is also why e.g. 
rockets fall from the sky - because systems tend to change so that old 
assumptions suddenly do not fit anymore. "I just updated the embedded 
web server, why did that manufacturing machine crashed?"

In my opinion, it all melts down not to a technical question - Linux can 
be hardened with "a bit" effort - but to a maintainability question. 
*Keeping* Linux hard real-time means establishing a kernel-wide 
programming model which supports the related requirements while still 
offering switches to tune for average performance. Who will like to hack 
new drivers if you always have to be aware of not creating the longest 
critical path of the kernel?

> As for Montavista announce, it has two sides, the marketing side, which
> is not RTAI project's business, [...]

Yes, it is marketing, and reacting on it officially may not be worth it.

However, a bit advertising for RTAI's benefits and capabilities in a 
quickly comprehensible way should be considered from time to time when 
there is a good chance to do it. A good solution is selected (and 
supported) because it was able to communicate the fact that it is good. 
Bad solutions are selected because some markting guys yelled louder and 

Such positive marketing does not have to be the 1001st task of the 
project maintainers and developers. It is foremost a task of pleased 
users as some kind of contribution to Open Source projects for which you 
even do not have to touch a single line of code. And there are thousands 
of ways to do this without shouting.


More information about the Rtai mailing list