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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
