RFC: Remove BSP_Configuration

[Joel Sherrill <joel@OARcorp.com>]

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.

You would still have the structure -- it would just be called Configuration.

> We haven't had a use of CPU_Configuration however.

CPU_Table I think is the name used.

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

It is clumsy and (I think) a historical artifact of not knowing how to 
do the ROM to RAM copy of initialized data variables with VERY old 
binutils and GCC.  Now this seems fairly settled and almost 
understandable.  So copying initialized data manually from a .data
variable to a .bss variable seems hokey and useless.


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

I really think it would only impact BSPs maintained outside the
source tree.  I can never do anythign about those but it is a simple
mechanical change to make on a single BSP.  More compliccated on
50. :)

> Gregm
> 


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