test for rtems_workspace_greedy_allocate

[Chris Johns]

On 8/2/21 4:50 pm, Chris Johns wrote:
> On 8/2/21 4:31 pm, Sebastian Huber wrote:
>> On 08/02/2021 06:14, Sebastian Huber wrote:
>>>
>>> We already have a ticket for this:
>>>
>>>
>>> https://devel.rtems.org/ticket/3982
> 
> Thanks. I am working on a solution. It is working but there is a small pause I
> think needs more investigation.
> 
>>> I am not sure how to fix this. Maybe we should force the sbrk() support to
>>> first give us all the memory of the system. Another approach is to remove the
>>> sbrk() support. What is the benefit of it? 
> 
> This is a reasonable question but beyond where I can current look. I suspect the
> reason is historical and if the call is still in use else where maybe it helps
> someone port a BSP to RTEMS. I do not know.

Just to follow up ...

sbrk() cannot be removed and we need to maintained and test it as a BSP level
interface.

I have found the libbsd test `thread01` fails on the PowwerPC because the
workspace greedy call (a copy of the heap version in rtems/src) fails the out of
memory check for the `rtems_bsd_get_curthread_or_null()` call. I now assume the
workspace on a shared powerpc BSP is being extended by sbrk().

This is an nice design idea where the sbrk() pool of memory can be given out to
the heap or workspace depending on the demands of the application. I can see
this being important to application frameworks like EPICS and so something we
should look to add to all architectures.

Chris