[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: Remove BSP_Configuration
Ralf Corsepius wrote:
On Thu, 2005-10-20 at 10:26 -0400, email@example.com wrote:
"Joel Sherrill <joel@OARcorp.com>" <joel.sherrill@OARcorp.com> writes:
> 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.
> + 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_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.