RFC: Remove BSP_Configuration

[gregory.menke at gsfc.nasa.gov]

"Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:
 > 
 > Hi,
 > 
 > While teaching the class last week, it occurred to me that an RTEMS
 > application has 2 copies of the Configuration Table and a separate 
 > pointer to it in the executive proper.  Maybe this can be simplified.
 > So I want some feedback.
 > 
 > Currently:
 > 
 >    + confdefs.h generated a structure named "Configuration"
 >    + shared BSP code copies that to BSP_Configuration
 >    + RTEMS proper does not know the variable name Configuration
 >      or BSP_Configuration, so it takes a pointer in as an
 >      argument to rtems_initialize_executive_early and saves
 >      that address in a global pointer variable.
 > 
 > My proposal would be to:
 > 
 > (1) Eliminate BSP_Configuration entirely.  Do not copy
 >      the generated Configuration to BSP_Configuration and
 >      modified Cofniguration as required in the BSP.
 
We have found BSP_Configuration to be useful at runtime, having a
well-defined struct to pull footprint info out of is nicer than defining
symbols in the linker script.

We haven't had a use of CPU_Configuration however.

The copying stuff related to these structs does seem a little clumsy,
but maybe its required or at least useful for other reasons.

 
 > (2) This is somewhat disjoint.  Let RTEMS assume that the
 >      Configuration Table has a known variable name and that
 >      it is "Configuration".  This will eliminate the global
 >      variable in RTEMS proper and might reduce some code.

Renaming the structs would be fine as far as we're concerned.

Gregm