GSOC:disable newlibc reentrancy

[Ralf Corsepius]

On Thu, 2008-05-08 at 09:54 -0500, Joel Sherrill wrote:
> 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.
Then answer: why is in CPUkit?

The OP explictly had asked to use it in cpukit.

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

* implications from POSIX and portability demand the OS to provide
features.
* applications demand further features.

>  Now we are just undoing this and making
> features optional at link time.
You will see where this ends ... I am not sure if I will want to watch
it - IMO you are leading RTEMS into a dead-end.

> > 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.
A toy OS to me, is one which doesn't provide the minimal requirements
POSIX and standards require an OS to provide.

> >>   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. 
It means you are linking one ABI against another one.

Use a linux compiler instead. If your toy-RTEMS project is successful,
this will work, if not, your toy-RTEMS project failed.

> > 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.
You want a SPECIAL COMPILE !!!!!

I think, it's time for me to leave this sick GSOC project, which never
should have been accepted, alone.

Ralf