RFC: Remove BSP_Configuration

[Ralf Corsepius]

On Thu, 2005-10-20 at 10:26 -0400, gregory.menke at gsfc.nasa.gov wrote:
> "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.
IIRC, this had been used to separate "initial ROM-based configurations"
from "actual runtime-configurations".
 
Ralf