On 10/2/21 4:12 pm, Sebastian Huber wrote:
> On 09/02/2021 23:17, Chris Johns wrote:
>
>> On 10/2/21 1:10 am, Sebastian Huber wrote:
>>> 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.
>
>>
On 09/02/2021 23:17, Chris Johns wrote:
On 10/2/21 1:10 am, Sebastian Huber wrote:
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
On 10/2/21 1:10 am, Sebastian Huber wrote:
> 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
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 bei
On Mon, Feb 8, 2021 at 6:14 PM Chris Johns 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 applicat
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 pau
On 8/2/21 5:12 pm, Sebastian Huber wrote:
> On 08/02/2021 06:50, Chris Johns wrote:
>
>>> 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
On 08/02/2021 06:50, Chris Johns wrote:
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
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
On 08/02/2021 06:14, Sebastian Huber wrote:
We already have a ticket for this:
https://devel.rtems.org/ticket/3982
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 i
On 08/02/2021 05:51, Chris Johns wrote:
On 8/2/21 2:41 pm, Chris Johns wrote:
Hello,
I see the call `rtems_workspace_greedy_allocate` is in `src/rtems` and publicly
available via the installed header file `rtems/support.h`.
Sorry the code is libcsupport.
Are there tests for this and similar
On 8/2/21 2:41 pm, Chris Johns wrote:
> Hello,
>
> I see the call `rtems_workspace_greedy_allocate` is in `src/rtems` and
> publicly
> available via the installed header file `rtems/support.h`.
Sorry the code is libcsupport.
> Are there tests for this and similar support calls?
>
> I ask becau
12 matches
Mail list logo
