CPU table removal comment

Chris Johns chrisj at rtems.org
Wed Dec 5 22:47:14 UTC 2007


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



More information about the users mailing list