GSOC:disable newlibc reentrancy

[Joel Sherrill]

Ralf Corsepius wrote:
> 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.
>
> The price: no POSIX, no c++, no networking, no ...
>
>   
That's not necessary.  We have always had at least two
non-POSIX but supported configurations:

+ Classic API only, no network
+ Classic API, network

The primary features we are talking about being
more optional are C library reentrancy and filesystem.
Making either of those optional can be done without
the addition of a special configuration .

I am nearly certain that you could no reentrancy
and no filesystem and RTEMS would be just as PSE51
compliant as long as you had POSIX enabled.

Again just pieces and parts, no special compiles,
just link time options to help users compose a system
that meets their requirements without doing any hacking
on RTEMS or special configures.
>> I would hardly call this a toy ...
>>     
>
> Ralf
>
>
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985