GSOC:disable newlibc reentrancy

[Ralf Corsepius]

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.
* A define in cpukit voids all the structural work we had done to cpukit
in recent years.

> And from a historical perspective, RTEMS was nothing but
> a scheduler until about version 3.2.
Ten years ago. 


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



>   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.

For bare-metal targets nobody needs RTEMS. He needs a minial scheduler
library.

Ralf