GSOC:disable newlibc reentrancy

[Joel Sherrill]

Ralf Corsepius wrote:
> On Thu, 2008-05-08 at 15:26 +0800, 阎淼 wrote:
>   
>> 2008/5/8, Ralf Corsepius <ralf.corsepius at rtems.org>:
>>     
>>> On Thu, 2008-05-08 at 14:54 +0800, 阎淼 wrote:
>>>       
>>>> Hi,
>>>>
>>>> I am trying to disable newlibc.c reentrant support.
>>>>         
>>> Why do you want to do this?
>>>       
>> That is one of the size reduction ideas of tiny rtems project.
>>     
>
> OK, in verbose: What you are doing is absurd. It means to cut-off rtems
> from newlib, turning all of newlib and the whole compiler unusable.
>   
The goal is not to disconnect RTEMS from newlib -- it is
simply to turn off the newlib reentrancy support on
systems that do not require, want, or have the resources
for it.  This will NOT turn off newlib at all and not break
any linkages.  It will not have any impact on prebuilt
toolsets or even prebuilt cpukits.

The RTEMS newlib reentrancy support is designed as
a user extension and in that light should be able to
be disabled.  But as an artifact of the implementation,
there is no way to disable it.  At some level, that forced
a feature onto RTEMS users at that time. Today, we
try to avoid adding required features.

On a bigger scale, I have been trying to get time to write
up something on RTEMS Execution Profiles so we have
real guidelines to judge by.  I have not named/defined
all of the profiles yet but see these two as definite and
the high end goal when --enable-posix is specified.

+ POSIX Realtime Controller System Profile (PSE52)  -
   simple file system implementation, one implicit
   process with threads support. 287 APIs according to
   one source.

+ POSIX Minimal Realtime System Profile (PSE51) -
    no filesystem, one implicit process with threads
    support. 626 APIs according to  one source.

NOTE: I have not yet found a complete list of those
            APIs to judge RTEMS by.  PSE53 and PSE54
            require processes.  PSE54 is full POSIX.  If
            someone can find a list of API calls required,
            I would like to know so we can audit against
            the profiles.

As a general rule, an RTEMS executable should NOT include
functionality the user does not require.  On top of this,
RTEMS is used in many systems that are safety critical
and have to go through source validation.  Leaving out
unused functionality is more important in these domains
to avoid code audits.

In addition to source validation, we also want to do
binary code coverage analysis of RTEMS and I
have done some already.  This requires making sure
all binary code in an executable is potentially reachable.
For example, POSIX threads specific functionality should
not be in the binary when --disable-posix is configured.

Validation efforts, application requirements, and as a side-effect,
to support smaller systems, we already support a profile without
POSIX threads (e.g --disable-posix or Classic API only) and without
networking.  But even if built, networking does not get included
in an executable unless you need it -- that's the goal for everything.

I have been asking some of the safety critical users to
provide information on what they do to RTEMS to
meet their domain's validation profile.  So far, these
requirements tend to overlap and are usually disabling
a subsystem we have historically thought of as always
necessary.  But usually was not even in very old RTEMS versions.

With the hindsight of history, these are mostly features
that were not in very old RTEMS versions (<4.0) and
were added without a clean way to disable them so
unintentionally they became part of the minimum
footprint. 

My goal for RTEMS is PSE52 compliance in full configuration
with every feature possible pluggable and configurable
so we can still support Classic API only, safety critical
validations of RTEMS, and RTEMS configurations that can
support applications in VERY low memory systems.

Dropping features out should largely be invisible to
the application and done automatically by confdefs.h.
The defaults should still provide a minimum reasonable
baseline for application development -- things like
newlib reentrancy should be ENABLED by default
and have to be explicitly turned off.

The ultimate goal is to provide a CPU Kit binary,
pre-built version of RTEMS that can be fully
PSE52 compliant or configured by the application
to fit into the smallest system.

I agree with Ralf that special builds are bad and should
be avoided. But users are hacking their RTEMS to
get lower configurations and these are the worst kind of
special builds.

RTEMS should be a collection of small pieces that
can be composed in many ways at application
configure and link time.   You can compose a big system
or a small system.  Nothing wrong with that.
> Ralf
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985