confdefs.h reworked

[Joel Sherrill]

Hi,

On Wednesday I plan to commit a fairly large
set of changes that resulted from an observation
from Matthew Riek.  He noticed that confdefs.h
reserved memory for the IDLE task twice.  Needless
to say this is unacceptable.  After fixing that,
many tests did not run. It turned out that that
single over by 1 task was covering up a number of
cases that did not account for heap overhead when
allocating their memory.

Before it was over, I had done a lot more analysis
and done some serious cleanup on confdefs.h and a lot
of code that had point issues with configuration.  The
modifications were too broad to back port unless someone
specifically pays for the engineering effort to do so.

confdefs.h is now MUCH easier to read (IMHO) and should
be more accurate.  For example, for one test and RTEMS
configuration, this eliminated about 21K of
overestimation.

In many places, it now relies on new helper macros
to make the math much more reliable.  I added two
internal macros to help with the estimation

+ _Configure_From_workspace(_size) - which
  adds the heap overhead to an allocation request.
+ _Configure_Object_RAM(_number, _size) - which is
  used for objects with IDs and accounts for how
  much RAM is used in total per object class

I added one visible macro which is too be used to
help make more accurate estimates on how much
memory you need for message buffers:

+ CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE(_messages, _size)
  so you can calculate the total memory for all queues by
  adding up the individual specific requirements.

I added lots of comments and reformatted a lot so
the indentation should help more in understanding it.

I have run all tests on psim with Classic, Classic
and POSIX, and with all APIs enabled.  At this point,
all single processor non-networked tests have been
checked on psim. 

Because each block allocated from the heap may be
subject to adding up for alignment purposes, it may
never be possible to have 0 bytes left after all
objects are allocated but this moves us much closer
to that point than we were.

Please let me know if you spot any over or under allocation
issues after this is committed.

-- 
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