CPU table removal comment

[chrisj at rtems.org (Chris Johns)]

Joel Sherrill wrote:
>
> Chris .. why don't you go ahead and post your description
> of the core constructor and let the community begin to
> discuss it.

I will.

I will also post something about the examples/net demo work I have done and 
the changes to the bsp cfg files. Until then anyone interested can take a look at:

  http://www.rtems.org/ftp/pub/rtems/people/chrisj/

> I put the bsp_xxx_hook()'s in exinit because I wanted rid
> of the CPU Table.  It worked and didn't require a whole
> lot of additional rework.  I had the potential to break
> enough without that.

Sound great.

> As I have mentioned in private emails, I would like the
> BSP framework to gain more initialization responsibility
> and thus reduce code duplication.  I really want the BSPs
> to be able to tell the framework (e.g. boot_card right now)
> that I have X bytes of RAM starting at address Y.  The BSP
> framework can then split that between the Workspace
> and C Program Heap as appropriate.
> 
> Long term, this lays the groundwork for having the ability
> to have a single heap like some other RTOS's which in
> conjunction with the unlimited object support, will be a
> nice combination.  All memory would be in a single pool
> for OS and application usage.
> By centralizing the splitting of memory and C library
> initialization, it would also be easier to disable things
> and deal with errors during initialization.

Excellent news. I had not seen the relationship between the cpu table and the 
heap.

> Getting rid of the CPU Table was the beginning of the
> process, not the end.

And I think core constructors can compliment this work by moving control to 
the BSP as well as providing more flexibility.

The core constructors change requires updated linkcmd files.

Regards
Chris