test for rtems_workspace_greedy_allocate

[Chris Johns]

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.

> Another approach is to remove the greedy allocation functions and test the no
> memory conditions differently. We could wrap the allocator function and let if
> fail every n-the call. With this you can write generic tests like:
> 
> for i=1,2,...
> 
>    let allocate fail in i-th call
> 
>   p = test()
> 
>   if p != NULL:
> 
>         done

I think greedy should have a separate test as it is an interface. A test means
sbrk can be tested because I am wondering if it is. Removing it and playing with
allocators not an option for me. There are too many powerpc BSP we have not been
able to test and have sat broken for a decade now. They are a tangle of
interconnected pieces that are fragile and the ISA bridge IRQ bug is an example.
If we cannot test all powerpc BSPs we need to step carefully. My efforts are
focused on a specific working PowerPC BSP.

Chris