(cvs head) CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK breaks

[Till Straumann]

Joel Sherrill wrote:
> Till Straumann wrote:
>> Recently a configuration option (CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK)
>> had been added. Unfortunately, on BSPs (e.g., the ones using
>> powerpc/shared/)
>> which rely on sbrk() to provide the first chunk of memory using sbrk 
>> is not
>> really optional.
>>
>> IMHO, confdefs.h is the wrong place for conditionally including sbrk
>> support.
>>
>> Instead, I'd propose to make this (yet another) variable to be
>> initialized by the
>> BSP (could be statically initialized to NULL and overridden by BSP's
>> bsp_start)
>>
>>   
> No.  I should have accounted for this case.  Define
> CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK in bsp.h.
> That's all you should have to do.
That would require *all* applications to include <bsp.h>
before <confdefs.h> --- IMHO not the best possible solution.

>
> Using sbrk() like this increases the minimum code footprint
> of all BSPs using it.  You not only have to include sbrk() but
> the code to extend a heap.
Sure but on the BSPs that currently use this feature memory
is abundant.

The solution I suggested (set rtems_malloc_sbrk_helpers from
bsp_start by BSPs which need sbrk) only requires linking sbrk
& friends on these BSPs.

Question: is it acceptable for a BSP to manipulate
rtems_malloc_sbrk_helpers from bsp_start() ?

T.
>
> FWIW this was just a step along the way to letting the application
> be able to configure whether it wanted one heap for RTEMS
> and the program or two (e.g. malloc heap and RTEMS workspace).
>
> Eventually I would like to see boot_card() call a BSP provided
> helper routine to obtain the address and length of memory
> available to be allocated to either the workspace or C program
> heap.  Then the code to split it is shared across all BSPs ,
> easier to maintain, and easier to switch between single and
> double heap configurations.
>
> --joel
>> -- Till
>>
>>
>>   
>
>