Hi Ralf Corsepius,
I regret your decision to not recommend RTEMS... perhaps you can provide
additional technical insight into the technical issues (as opposed to personal
issues) you're observing.
Although your input relating to the need for maintaining a deprecation period
of removal of the thread-specific atexit() support for RTEMS should be verified
for accuracy (do the changes actually impact any RTEMS API's?), I politely
disagree with the tone of voice in the below email...
Clearly we want to encourage participation by using wording such as "I would recommend just
deprecating the thread-specific atexit() method until the next RTEMS release"... or "We
should let the upstream (Newlib) maintainers make that decision" or "Can we provide continued
support in a patch in rtems-tools until the next release?)...
If we are to improve the SMP support, we need additional information on EXACTLY
what the TECHNICAL issues are with it...
We are currently working on devising a release process... if you have specific
technical input to provide, please elaborate...
Just as there is an RTEMS steering committee, we are working on forming an
RTEMS process committee and release committee... of course it's an open project
(so anyone can provide suggestions to this mailing list)
If you do not feel RTEMS is worth recommending, I think you should consider
moving on to another free and open real time operating systems, or embedded
system that you would be happy with, such as:
eCos
Prex
RobotOS
There are products provided by RTEMS, some of which are through governmental
agencies and commercial organizations:
rtems.org/wiki/index.php/RTEMSApplications
If you change your mind and decide to continue participating in RTEMS, please
consider committing the process documentation that was submitted to the
bugzilla a while ago...
https://www.rtems.org/bugzilla/attachment.cgi?id=1512
Or write your own process documentaion and propose it...
Thanks for your participation in the past with RTEMS, looking forward to either
getting specific criticisms of the SMP scheduler, and technical process
suggestions, or hoping you will find a project that suits your process needs if
RTEMS will not meet your process needs...
Thanks,
Cindy
________________________________________
From: rtems-devel-boun...@rtems.org [rtems-devel-boun...@rtems.org] on behalf
of Ralf Corsepius [ralf.corsep...@rtems.org]
Sent: Monday, July 08, 2013 8:38 AM
To: Gedare Bloom
Cc: RTEMS
Subject: Re: Patches for Newlib and RTEMS
On 07/08/2013 05:03 PM, Gedare Bloom wrote:
On Mon, Jul 8, 2013 at 10:46 AM, Ralf Corsepius
<ralf.corsep...@rtems.org> wrote:
On 07/08/2013 03:33 PM, Sebastian Huber wrote:
Hello,
the patches sent today for Newlib and RTEMS require a re-build of the
tool chain.
=> These patches are not adequat at this point in time.
In particuliar RTEMS needs to be adapted to not rely upon them.
Please elaborate on the particular weaknesses that render these
patches inadequate.
Breaking the toolchain this kind of radically and forcing all users to
rebuild their toolchains is utter rude and hostile towards users - It's
prohibitive - I's naive, unprofessional and amateurish.
A responsible project management makes sure the project handles such
ABI/API changes for at least a transitional period of time. It's what we
(In most cases me) have been doing for many years.
It's likely only thanks to the fact us having done so, users, comprising
you haven't noticed.
The changes are
1. Removal of the thread-specific atexit() support to reduce the size of
struct _reent. See discussion on the Newlib list.
2. Usage of __DYNAMIC_REENT__ for SMP support and simpler context
switching.
3. POSIX cleanup push/pop implementation change.
Whether these patches make sense is a different question. I think they are
too intrusive and should all be rejected.
The development of SMP support in RTEMS is necessarily complicated.
Sorry, but IMO, the SMP implementation is RTEMS is crap.
Ralf
PS.: Honestly, RTEMS needs to return to a more organized development model.
The way RTEMS currently is being developed to me qualifies as unprofessional
hackery.
If anything, the current model of development is more organized and
professional than before.
The current model is no release process, no project management, no
release manager, no product.
ATM, I would have to lie when recommending RTEMS to anybody,
Ralf
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
