Patches for Newlib and RTEMS

[Thomas Doerfler]

Hi Cynthia,

thank you for taking the time and patience to elaborate this (although
this should not be required for somebody working so long in this project).

My only comment to your posting: FULL ACK.

wkr,

Thomas.

Am 08.07.2013 19:40, schrieb 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
> 
> 
> 
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
> 


-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler
Dornierstr. 4
D-82178 Puchheim
Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18 94 741-12
Fax:   +49-89-18 94 741-09
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.