Montavista's "Open Source Real-Time Linux Project" again
jan.kiszka at web.de
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