Re: RFC: Remove BSP_Configuration

["Joel Sherrill <joel at OARcorp dot com>" <joel dot sherrill at OARcorp dot com>]

Ralf Corsepius wrote:
> On Thu, 2005-10-20 at 10:26 -0400, gregory.menke@gsfc.nasa.gov wrote:
>
> > "Joel Sherrill <joel@OARcorp.com>" <joel.sherrill@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".

And to let RAM downloaded images be restarted.  We didn't know how to 
have a 2nd copy of the .data when in a.out/coff back in the dark ages. 
That's where it started.  Now I think this is easy to handle.

But isn't this now what this type of trick now accomplishes:

  /* initialized data section
     ld will load this at __text_end in the output file,
     but will actually locate it in ram.  By doing a
     memcpy( &_data_start, &_text_end, (&_data_end - &_data_start);
     during startup, we initialize our nonzero globals . */
  .init : AT (__text_end)
  {
    __data_start = .;
    *(.data)
    __data_end = .;
  } > ram


I think it would simplify things.  But I am concerned that
it is requiring the Configuration Tables to have a fixed name.
At one level it doesn't bother me at all. But at another, I worry
that I am missing something.

--joel