[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
cleaner & greener (was Re: A patch for RTEMS4.10.0 PowerPC heap space initialization)
- Date: Tue, 17 May 2011 13:58:15 -0500
- From: strauman at slac.stanford.edu (Till Straumann)
- Subject: cleaner & greener (was Re: A patch for RTEMS4.10.0 PowerPC heap space initialization)
On 05/17/2011 01:20 PM, Till Straumann wrote:
> On 05/16/2011 11:59 PM, Chris Johns wrote:
>> On 17/05/11 5:27 AM, Kate Feng wrote:
>>> The PR is at http://rtems.org/bugzilla/show_bug.cgi?id=1797
>>> Thanks for all the feedback. I am glad that the API is more or
>>> less verified. Previously, I could not decide where to place the macro.
>>> #define CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK
>>> The patch for the mvme5500 BSP is updated as well at
>> Thanks for sorting this. I will leave the patches for Till to review and
> OK, will do.
As a matter of fact, I'm thinking of adding
to the bspopts.h of the BSPs that currently use
That way, the entire feature may be configured away
by the user if they want.
> Note that there will be a slight asymmetry if you configure a unified
> work area and have sbrk support. While allocating from the unified heap
> via 'malloc()' then the heap is transparently extended via sbrk().
> However, the unified heap is *not* extended transparently when you
> allocate via _Workspace_Allocate() / rtems_workspace_allocate().
> Given that the entire sbrk business is only required for special
> purposes I assume we can live with that asymmetry for now (and
> the unified heap can always be extended explicitly via 'sbrk'
> and _Heap_Extend()).
> - Till
>> I have finished PR1774 so this is all that needs to be applied to start
>> the 4.10.1 release process.
>> rtems-users mailing list
>> rtems-users at rtems.org
> rtems-users mailing list
> rtems-users at rtems.org