On 09/02/2021 14:59, Gedare Bloom wrote:
sbrk() cannot be removed and we need to maintained and test it as a BSP level
interface.
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.
Please raise a ticket, this can be a GSoC project idea I think?
What is the benefit of sbrk() compared to the unified work areas? Do
address fragmentation/performance issues it makes more sense to replace
the first fit allocator with something else.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
