(cvs head) CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK breaks

[Joel Sherrill]

Till Straumann wrote:
> 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.
>
>   
They already are supposed to.  The BSP includes
multiple things for device drivers.  You can't
generate a complete configuration otherwise.

And yes.. I don't see this documented explicitly.
It is done that way in all examples.
>> 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.
>
>   
Your perspective is biased.  It is only the unix BSP
and apparently the PowerPC ones based upon shared.
> 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() ?
>   
Off hand, I don't see any reason that wouldn't be OK.

I guess it could be done that way instead of the confdefs.h way.

I don't know how the one heap versus two will eventually
play out in the code so we may end up revisiting this.

--joel
> 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
>>>
>>>
>>>
>>>       
>>     
>
>
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985