RFC: Remove BSP_Configuration

[gregory.menke at gsfc.nasa.gov]

"Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:
 > gregory.menke at gsfc.nasa.gov wrote:
 > > "Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:
 > >  > 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.

No problem for us then.  We don't use it extensively, but it is handy
for reporting stuff cross-platform- mostly recording heap & workspace
figures for instance.

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

Agreed.


 > 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. :)

Sounds like it's likely not to cause much more trouble than setting up
cpukit did- a bit of grumbling and confusion at first...

Gregm