RFC: Remove BSP_Configuration
ralf.corsepius at rtems.org
Thu Oct 20 14:35:40 UTC 2005
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".
More information about the users