Rich Cloutier wrote:
> I think at issue here is the fact that RTL's development is
> occurring at too fast a pace to allow in-line development.
>
> In other words, the "stable" releases cannot be made more
> stable except by diverging from the main development path. This
> is the only method that makes sense if RTL is to be used in
> such super-critical applications as that which Mr. Lillard has
> mentioned. Once thorough testing and debugging of a stable release
> has qualified it for these super-critical applications,
>
> The bug fixes cannot then be incorporated into the latest code
> and used by these users, because recently added functions will
> not have had the benefit of such thorough testing.
This is precisely the problem.
> Either of two approaches can be taken:
>
> 1. Each "stable" release could be beaten to death by interested
> parties, and terminate at a truly stable minor release level
> (dead end,) or,
>
> 2. There could be a second development path that lags the first,
> testing and debugging each release only when the participants
> determine that the previous release is truly "bug free." This group
> would of course submit bug fixes to the faster-paced releases to
> improve the stability of the "core."
Actually 2 will converge to 1, for each major release and for
each architecture permutation of that release.
I see a need for several versions of RTL. For instance RTL can
scale down nicely for diskless embedded designs which use a CPU
that lacks memory management. Support for a ROM'able kernel would
be needed too. I see the v2.0 kernel as quite suitable for these
applications and ready for serious QA. v2.0 could very well be the
first RTL kernel which meets the standards required for critical
applications.
The v2.2 kernel, later and greater though it may be, will not have
the maturity of v2.0 for at least another year, probably longer.
It is likely to take that long for the bug-rate to taper off,
so everybody keep pounding on it, it will get there.
You are right, over time the qualified kernels will approach
a dead end. This is a good thing. Minor tweaks may be needed
from time to time for mask revisions of a given CPU. Motorola,
for example, is on an evolutionay path with their m683xx and
Coldfire series processors. Thus mask changes may encourage
(hopefully not require) changes to RTL.
> This second option should be the model for open software
> development anyway
Yes, Yes, Yes.
> however not all users (myself included) are
> qualified to debug the RTL kernel when we find a problem with it.
Pitch in where they can. If you have the time,
you could work on documentation or QA.
Probably the best solution is for a company to control releases
from option 2 above. Sounds like a business opportunity to me.
Unfortunately, Cygnus is doing their own thing and will probably
see a commercial RTL effort as competition for ecos.
Ray
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
