[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GSOC:disable newlibc reentrancy
- Date: Thu, 08 May 2008 17:41:47 +0200
- From: ralf.corsepius at rtems.org (Ralf Corsepius)
- Subject: GSOC:disable newlibc reentrancy
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.