CPU table removal comment
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 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:
> 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.
> 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
> 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.
More information about the users