cleaner & greener (was Re: A patch for RTEMS4.10.0 PowerPC heap space initialization)

[Joel Sherrill]

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
>>>>> 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 ?
bspopts.h is automatically generated so the answer is that
prototypes can't go there.

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


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