RFC: Remove BSP_Configuration

[Ralf Corsepius]

On Thu, 2005-10-20 at 11:52 -0500, Joel Sherrill  wrote:
> Ralf Corsepius wrote:
> > On Thu, 2005-10-20 at 10:46 -0500, Joel Sherrill  wrote:
> > 
> >>Ralf Corsepius wrote:
> > 
> > 
> >>>I think we are talking pass each other:
> >>>
> >>>A "initial ROM-configuration" is static, r/o and non-volatile in most
> >>>cases, while a runtime-configuration is dynamic, r/w and volatile in
> >>>most cases.
> >>
> >>But there was/is no distintion between the values of the ROM copy and 
> >>RAM copy.  Both are intended for a single configuration of the BSP 
> >>whether that is to run out of ROM or RAM.
> >>
> >>This was really just a hack that dates back to not having the ability to 
> >>place the initial values for the .data section in a separate location 
> >>and having start code copy it.  The .data section cannot permanently 
> >>reside in ROM because it is initialized but writeable.
> >>
> >>
> >>>To support this, you must have 2 sets of configurations being available
> >>>at run-time. Simply copying anonymous memory from ROM to RAM is not
> >>>sufficient. You will want to know each and every detail about both
> >>>configurations otherwise you won't be able to switch between.
> >>>
> >>>[Consider "warmstart"/"SW"-resets and the like]
> >>
> >>Yes but the current setup doesn't support this either.
> > 
> > 
> > Have a look into c/src/lib/libbsp/sh/gensh1/startup/bspstart.c
> > and you'll see that we use it -- we even use CPU_Table.
> 
> We are missing each other today. :)
> 
> Yes you are using the BSP_Configuration structure.  But with no magic 
> switch between multiple configurations that I see.  As long as 
> Configuration (or rtems_configuration) ends up initialized and in RAM,
> it still works.
We are treating Configuration as static, r/o, non-volatile initial
configuration but are treating BSP_Configuration as a dynamic, r/w, and
volatile run-time configuration.

What you don't see is what applications do with BSP_Configuration!

> Yes I will end up mechanically having to edit every BSP which references
> BSP_Configuration to use the new name.

Which? Are you serious in wanting to call it "Configuration"? 
Pardon, but this would be a bad choice!

Ralf