GSOC:disable newlibc reentrancy

[Sven.BIEBAUT at be.thalesgroup.com]

> -----Original Message-----
> From: Ralf Corsepius [mailto:ralf.corsepius at rtems.org] 
> Sent: 08 May, 2008 16:01
> To: Sven.BIEBAUT at be.thalesgroup.com
> Cc: joel.sherrill at oarcorp.com; rtems-users at rtems.org
> Subject: RE: GSOC:disable newlibc reentrancy
> 
> 
> On Thu, 2008-05-08 at 15:46 +0200, Sven.BIEBAUT at be.thalesgroup.com
> wrote:
> 
> > > For bare-metal targets nobody needs RTEMS. He needs a minial 
> > > scheduler library.
> > > 
> > 
> > with a lot of evidence and years of correct working 
> history, support 
> > for lots of different processors and a large supporting user base
> > 
> > And the possibility to add com ponents as your system requires it 
> > during its 20 odd years of support to the customer !
> Rip out score, throw away all the historic ballast, and turn 
> it into a standalone library.
> 
> It wouldn't be an OS nor RTEMS anymore, but it would be an 
> RTEMS api-complicant scheduler library. No need for a special 
> compiler, no newlib, simply use a bare metal cross-compiler.
> 
What makes RTEMS RTEMS ? the special compiler or newlib ? 
No, the code itself that has been nurtured into maturity ( and still is so,
judging from all the activity on the mailing list).
It does not mean throwing away anything, just allowing you to choose more
flexibly what you need.

I recently had to chose another minimal kernel because my preferred option -
RTEMS - couldn't get low enough in size. I paid deerly for it before it
would function as desired...

Sven

> The price: no POSIX, no c++, no networking, no ...
> 
> > I would hardly call this a toy ... 
> 
> Ralf
> 
>