CPU table removal comment

[Till Straumann]

Joel Sherrill wrote:
> 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.
Hmm - there are applications where having multiple
regions from where to allocate memory is desirable.

Consider run-time loading of PPC binaries. Normally,
they must all reside within a single 32M block of memory
for ordinary branches to work.

Hence, it would make sense for the loader to reserve
the lowest 32M of memory for loadable-object's text
segments.

Another segment of memory could be set aside for
ppc SDA areas etc.

FWIW
-- T.
> 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
>