GSOC:disable newlibc reentrancy

Ralf Corsepius ralf.corsepius at rtems.org
Thu May 8 15:41:47 UTC 2008


On Thu, 2008-05-08 at 10:05 -0500, Joel Sherrill wrote:
> 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:
POSIX doesn't mean pthreads.

It means printf, str*, mem*, malloc, etc. ...

> 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,
Then remove this silly CONFIGURE*REENTRANCY crap you added to RTEMS. 

THIS makes builds using it a SPECIAL build and renders shipping binaries
of cpukit IMPOSSIBLE.

Ralf





More information about the users mailing list