"Raymond Y. Lillard" wrote:
> 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.
I've been debating the possibility of making a ROM-based Linux systm
myself, but have yet to find help with such a project. In my testing, the
2.0 kernel is fine for such an application. However, the problems then
comes from booting and running such a specialized system. I'm afraid my
own coding areas are much too limited to develop such a project to it's
finished state.
>
>
> 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.
>
So far, I have only found 2 bugs in 2.2.2, which is far less than the bugs
I found in 2.0.33.
>
> 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.
>
Well, such a solution has been proposed within my own company. We've been
seeing an opportunity here for awhile, but so far have yet to find the
additional staff/funding my company needs to exploit this opportunity.
Nate
--- [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/
