(cvs head) CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK breaks

[Joel Sherrill]

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.

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.

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