cleaner & greener (was Re: A patch for RTEMS4.10.0 PowerPC heap space initialization)
joel.sherrill at OARcorp.com
Wed May 18 14:05:09 UTC 2011
On 05/18/2011 08:57 AM, Kate Feng wrote:
> Till Straumann wrote:
>> 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
>>>>> #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
>>> 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.
> I was thinking to use a common header as well. I assume the
> configuration you meant
> would only touch the bspopts.h of the BSPs that currently use
> As long as it does not affect the bspopts.h of the other BSPs, that
> would be fine.
> If Joel agrees, it would be good to move
> uintptr_t bsp_sbrk_init(uintptr_t, uintptr_t*);
> from bootcard.c to bspopts.h as well.
> Is it easy to do that without me updating the patch so that there is no
> broken ring ?
bspopts.h is automatically generated so the answer is that
prototypes can't go there.
>>> 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
>> rtems-users mailing list
>> rtems-users at rtems.org
> rtems-users mailing list
> rtems-users at rtems.org
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
More information about the users