RFC: Remove BSP_Configuration

Joel Sherrill <joel@OARcorp.com> joel.sherrill at OARcorp.com
Thu Oct 20 14:42:47 UTC 2005


Ralf Corsepius wrote:
> 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".

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



More information about the users mailing list