Patches for Newlib and RTEMS

Ralf Corsepius ralf.corsepius at
Mon Jul 8 15:38:15 UTC 2013

On 07/08/2013 05:03 PM, Gedare Bloom wrote:
> On Mon, Jul 8, 2013 at 10:46 AM, Ralf Corsepius
> <ralf.corsepius at> 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,


More information about the devel mailing list