Patches for Newlib and RTEMS

[Rempel, Cynthia]

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-bounces at rtems.org [rtems-devel-bounces at rtems.org] on behalf of Ralf Corsepius [ralf.corsepius at 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.corsepius at 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 at rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel