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