GSOC:disable newlibc reentrancy

[Joel Sherrill]

Ralf Corsepius wrote:
> On Thu, 2008-05-08 at 08:30 -0500, Joel Sherrill wrote:
>   
>> Ralf Corsepius wrote:
>>     
>>> On Thu, 2008-05-08 at 20:43 +0800, xu ray wrote:
>>>
>>>       
>>>> libc_global_reent structure will take 1kb SRAM. This relic is too big
>>>> for a system with only a few k sram. Though the pointer to libc_reent
>>>> is used in thread dispatch, it is not a must for thread dispatch.
>>>>
>>>>         
>>> What you are doing is abusing the RTEMS infrastructure for something
>>> which isn't RTEMS, nor using the RTEMS toolchain.
>>>
>>> Your are converting RTEMS into a bare metal skeleton and abusing the
>>> RTEMS toolchains to build a bare-metal based minimal scheduler library.
>>>
>>>
>>>       
>> More than anything else, it is treating RTEMS as a set of
>> pieces that can compose a variety of systems at application
>> configure time.  No special compiles, no differences in the
>> toolset.
>>     
> Gradually I getting angry at you:
>
> * A define in cpukit is a special compile.
>   
Not in confdefs.h -- that file is NOT compiled as part of cpukit.
It is installed and processed at application compile and link time.
No change in confdefs.h impacts conditional compilation of
cpukit or adds another build variant to cpukit.
> * A define in cpukit voids all the structural work we had done to cpukit
> in recent years.
>   
But this isn't adding another variant -- it is taking something
that is now always in the executable and making it optional.
It is not turning off building it and should NOT!!!

I do NOT want any TinyRTEMS to add new conditional
defines to cpukit.  Just split things and make them
optional -- at application configure/link time, pick
heavy or light implementation.
>   
>> And from a historical perspective, RTEMS was nothing but
>> a scheduler until about version 3.2.
>>     
> Ten years ago.
>
>   
Maybe longer. :-D 

But the point is that whether we intended to or not,
we made decisions that EVERY application wants
feature X.  Now we are just undoing this and making
features optional at link time.
> Then newlib had been adopted, RTEMS had been made POSIX compiliant ....
> now, you are reverting all this ten years of work and turning RTEMS into
> toy
>
>   
Toys do not get flight validation and the features we
are making optional at link time are precisely the ones
that are removed to produce an RTEMS configuration
that is validatable.
>
>   
>>   In retrospect, we should
>> not have created the linkages between subsystems that made
>> so many things required when they really were not.
>>
>> I do not want special tools or special builds of RTEMS
>>     
> You will have to, because the RTEMS toolchain's ABI doesn't match to
> your libc-less TinyRTEMS. It's a bare-metal target.
>
>   
Just because libc is not reentrant, does NOT mean it is
not there or useable.  Even ignoring "FILE *" methods, you
still have libm, str*, mem* and a host of other useful
capabilities.

The application can use XXX_r methods and avoid needing
reentrancy on another set of methods.

And even without reentrancy, you can still use the FILE *
methods safely if the application only uses them from
one thread. 


> For bare-metal targets nobody needs RTEMS. He needs a minial scheduler
> library.
>
>   
Yes. And nothing prevents RTEMS from being reducible to
a threads library except the forced inclusion of a few features.

I do not want this to be THE ONLY RTEMS configuration.
I want it to be AN RTEMS configuration.  Having this restricted
configuration in no way diminishes the overall goal of having
a PSE52 compliant environment.

FWIW I would like to see the complete set of PSE51 calls required.
It says no filesystem which would imply a feature we think is
always needed is in fact optional to POSIX.  Since PSE51 is ~400 calls
smaller than PSE52, that would look like file related calls are dropped.

> 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