GSOC:disable newlibc reentrancy

[Sven.BIEBAUT at be.thalesgroup.com]

> -----Original Message-----
> From: rtems-users-bounces at rtems.org 
> [mailto:rtems-users-bounces at rtems.org] On Behalf Of Ralf Corsepius
> Sent: 08 May, 2008 15:40
> To: Joel Sherrill
> Cc: rtems-users at rtems.org
> Subject: Re: GSOC:disable newlibc reentrancy
> 
> 
> 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.
> 

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 !


I would hardly call this a toy ... 

My 2 cts.

> Ralf
> 
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>