[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)



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 
>>>> macro.
>>>>
>>>> #define CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK
>>>>
>>>> The patch for the mvme5500 BSP is updated as well at
>>>> http://www.rtems.org/bugzilla/show_bug.cgi?id=1786
>>>>
>>>
>>> Thanks for sorting this. I will leave the patches for Till to review 
>>> and
>>> commit.
>>
>> OK, will do.
>
> As a matter of fact, I'm thinking of adding 
> CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK
>
> to the bspopts.h of the BSPs that currently use
> powerpc/shared/startup/sbrk.c
>
> 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 
powerpc/shared/startup/sbrk.c.
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 ?

Kate

>
> T.
>
>>
>> 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.
>>>
>>> Chris
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users