Release or Snapshot for Mission-Critical System

Ralf Corsepius corsepiu at
Tue Jan 21 11:53:38 UTC 2003

On Tue, 2003-01-21 at 07:34, Jason Hinze wrote:
> Hello,
> I'm new to RTEMS and I'm trying to get a feel for the community's
> consensus on which version of RTEMS to use for mission-critical
> development.  I've poked around the ftp site, and perused the
> 'RTEMS Users' and 'RTEMS Snapshots' mailing lists, and I can't
> get a good idea of what the accepted best practice is.
> As far as I can tell, 4.5.0 is the latest full release; but it seems to
> be 2 - 2.5 years old. 

Yep, it old and should have been replaced for long ;)

>  I see quite a bit of discussion that seems to
> indicate that people are happily using snapshots, but it also seems
> that they do encounter a fair number of early-adopter issues.

Basically, the snapshots are supposed to be stable, however also serve
the purpose of sorting out issues by "mass trials".
Anyway, at present time we are slowly approaching a new release, so,
though there might be (there definitely are ;) ) a nit here and there,
the status of snapshots can be considered to be very close to the "next
release" (call it "beta-stable", if you like to).

And yes, IMO, most of the issues reported by users are "early-adopter
issues" of people not being familiar with the gnu-tools. 
As working with RTEMS often seems to be their first contact with
Unix-ish systems and cross-building, I am inclined to think most of
these problems to stem from general unfamiliarity with such systems and
the general complexity of cross-building.

> For the system we will be developing, stability is paramount.
> I'll gladly give up on features, tidiness, and such, for a proven-
> stable foundation. 
It depends on how you define "stability" and is almost impossible to

1 Building stability.
4.5.0 is known to suffer from problems wrt. this topic. snapshots/4.6.0
should be _much_ better.

2 integration/extension (source-tree layout)-stability 
Much has changed since 4.5.0 here. If you want to "lean to community
support for assistance/bugfixes/upgrades", use 4.6.0/snapshots.

3 code-structure/API stability
Many things have changed since 4.5.0, however, essentially the APIs
should be backward compatible to 4.5.0.

4 run-time-stability
As far as RTEMS code is concerned: Many bugs have been fixed, developers
believe to have improved the code, but ... ;)

This also is highly target and tool-chain dependent - Here, only
personal experience with your own hardware will be able to tell you.

>  Once our system has been deployed, it
> will be somewhere between extremely difficult and completely
> impossible to fix any software issues.

> So, what do y'all think?  Do we use 4.5.0, the latest snapshot,
> or some known-by-many-to-be-good snapshot?
Well, at present time, I would recommend you to try the latest
snapshots. They are scheduled to converge to rtems-4.6.0 in near future.
Also remember, RTEMS is an OpenSource community project, so whenever you
think to have encountered a problem, you have the opportunity to share
the "mutual benefits" of "OpenSource" :-), i.e. report bugs/receive bug
reports from others, contribute bugs fixes etc.

> Also, if we use 4.5.0 or a non-current snapshot, do we want
> to use the versions of the GNU tools that were originally
> associated with that release / snapshot of RTEMS,

>  or the latest versions of the GNU tools?
Generally no, but ...YMMV.

Basically, each new version of the gnu-tools fixes known issues with the
toolchain, but also can trigger new issues with RTEMS or suffer from
incompatibilities. (The most significant incompatibilities are
introduced from RTEMS interaction with newlib - Since 4.5.0 many files
have moved between newlib and RTEMS, so you can't expect a toolchain
which worked with older RTEMS to work with newer RTEMS versions).


More information about the users mailing list