CPU table removal comment

[Joel Sherrill]

Chris Johns wrote:
> Till Straumann wrote:
>> I noticed that with the CPU table gone
>> exinit now always calls bsp_xxx_hook().
>
> IMO this should be a core constructor and exinit should know nothing 
> about any of this. See PR1253.
>
Chris .. why don't you go ahead and post your description
of the core constructor and let the community begin to
discuss it. 

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.

Getting rid of the CPU Table was the beginning of the
process, not the end.
>>
>> While the BSP certainly can override these hooks
>> by defining it's own versions there is currently
>> no way to call the generic version from libbsp/shared
>> from the BSP's 'special' hook -- something that I'd consider
>> desirable.
>>
>> IMO, an additional level of indirection is required
>> (was previously provided by the CPU table).
>> E.g., the bsp_xxx_hook()s could be simple
>> wrappers  calling bsp_xxx_hook_generic().
>> If a BSP provides it's own bsp_xxx_hook it still
>> could call bsp_xxx_hook_generic() from there...
>>
>
> The BSP could have its own group of constructors which can be ordered.
>
> Regards
> Chris