Hi Kevin,

 

               Thanks for the e-mail.

               The main idea of the whole patchset is to support manual memory management for the OS.

To achieve that:

• Change OS handle to OS-Wrapper handle is required to manage resources effectively.
• Suspend the child thread, so that it gives parent thread the opportunity to free resources and safely terminate/delete the child thread, which is the issue with `os_wrapper_thread_exit()` as it can’t free its own

manually managed resources.

 

               Hope this answers your query.

 

Thanks & Best Regards,

Vikas Katariya

 

 

Hi Vikas,

 

I’m seeing two topics here if I understand correctly.

The first one is how to deal with memory management in the os wrapper implementation.

The second one is how to safely “exit” and “delete” a child thread.

 

Please first check if my understanding is correct.

For the first topic, except the handles of threads, semaphores or mutex (which are the OS handles I guess), the OS wrapper needs some extra handles for resource handling.

For example the pointer of the memory allocated in the OS wrapper API. The two handles forms the new OS wrapper handle you proposed.

 

For the second topic, can we just terminate or delete the child thread by itself after it has done its job?

 

 

 

Hi all,

 

Thanks for the e-mail.
I would like to highlight a few issues with the current API implementation.

• It isn't good for OS which relies on manual memory management, the current API doesn't give an opportunity to free any resources which were in use.
• The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources to be freed which are not managed by the OS.

 

So a change in the API implementation is required to address the above issues.

• Use `os_wrapper_current_thread_suspend()` and `os_wrapper_thread_terminate(handle)` API, ensuring we suspend and terminate safely, enabling it to free allocated resources.
• Remove `os_wrapper_get_handle()` to make sure we differentiate between OS wrapper handle and OS handle. The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle because implementations can't always create an OS-wrapper handle from an OS handle.

 

Comments towards the arguments:

• If we go with `os_wrapper_thread_exit()` to exit a child, then OS can allocate that resource to another purpose instantly and if we were to pass that handle to `os_wrapper_thread_delete(handle)`, we still risk corruption.
• If we go with `os_wrapper_thread_exit()` suspending the thread Or `os_wrapper_thread_delete(handle)` performing a NOP, it changes the semantics of what API intends to do and is not a natural way of moving forward. Also, it may confuse developers by making exit suspend instead of exit, or delete not delete anything.
• If we go with `os_wrapper_thread_exit()` performing a NOP and `os_wrapper_thread_delete(handle)` performing a termination of the thread, there are few things to consider here:
• It changes the semantics again for exit, but on some OS if the thread has finished its operations it will either exit or suspend itself as there is nothing to execute further.
• If the thread exits then os_wrapper_thread_delete(handle) will result in error.
• If we add a wrapper variable that captures info on if the thread has been exited to check deletion is safe or not, there few things to consider here:
• Adds an additional maintainability burden.
• Tracking if a thread has been exited or not adds a cost in RAM that would not be needed if the API had a good shape. Seeing as we all develop for embedded devices here, we should be very careful with RAM use.
• It can't figure out its identification because the OS-wrapper handle is not passed in `os_wrapper_thread_exit()`. Differentiating between the right handle is required to ensure we track the right thread information.

 

Depreciating the old API will ensure the following:

• Future applications are portable to any OS that needs manual memory management.
• It forces out-of-tree applications using the wrappers to know they need to make a change in order to be portable to operating systems that require manual memory management.
• The in-tree applications will be refactored as part of this API change.

 

Further, if there is a matter of handling deprecation of API, then I would like to know how that can be achieved in TF-M?

 

Thanks & Best Regards,

Vikas Katariya

 

 

Hello,

 

Agree with Jamie seeing not enough arguments for extension of existing API. Looks like the required functionality can be hidden inside a specific os_wrapper, which is a main purpose of it.

@Vikas, could you explain a bit differently why you are blocked with the current API?

 

Cheers,

Anton

 

 

 

Hi,

 

From the architecture point of view, when an “owner” (sw entity) defines an API, the best is to do that based on it’s own needs. This gives the most flexibility and makes the API best withstand future challenges. Sometimes this is not possible. An example for this is the TRIM functionality of SSD storage, where the file-system must give extra information to the storage. In this case the extension of the API is driven by the implementation and thus implementation details. This is risky as different implementations may have conflicting needs, and sometimes the API cannot fulfill both.

If your case, a possible solution is to implement the os_theread_delete() and an empty function. If that is not possible, then a wrapper can be added where a variable captures info on if the thread has been exited, and thus if deletion is safe or not. If it is, then os_thread_delete() can exit without doing anything.

The call sequence of suspend and the delete is specific to the OS you are using or to the way you use it. Do you think does here a strong reason exist to go for an API extension driven by the implementation? I don’t have all details, but as far as I understand the specific cases you described I don’t see an imminent need for the API change.

/George

 

 

Hi Jamie,

 

               Thanks for getting back.

 

It’s because of os_wrapper_thread_exit() is used to exit the child thread in the SST test, which means the handle is no longer valid for os_wrapper_thread_delete() to operate on, resulting in an error.

 

               The ideal way to do this properly is to use os_wrapper_thread_suspend() and then os_wrapper_thread_delete() from the parent thread.

 

Thanks & Best Regards,

Vikas Katariya

 

 

 

Hi Vikas,

 

I still do not really understand the rationale for these changes. If dynamic memory allocation inside the os_wrapper shim is really what you want to do, then what is stopping you from implementing the following?

 

os_wrapper_thread_new()

{

    malloc(external_to_os_resource)

 

    /* create thread */

}

 

os_wrapper_thread_delete()

{

    free(external_to_os_resource)

}

 

Kind regards,

Jamie

 

 

Hi all,

 

               The patch set has been updated with further changes:

 

• https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294

OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool.

The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management.

 

For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak.

Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required.

 

The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate().

If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management);

an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource.

 

• https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299

These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage.

Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management.

The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS.

 

For example:

struct {

os_handle;

external_to_os_resource;

};

The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle.

In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly.

Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers.

 

• https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency.

 

Please review and share your thoughts.

 

Thanks & Best Regards,

Vikas Katariya

 

 

 

Hi all,

 

I am proposing new changes to OS wrapper layer to help other RTOS use dynamic memory allocation.

 

OS wrapper layers help to create Mutex, Semaphores, and Thread on RTOS. The wrapper is designed to use static allocation of memory/objects

from predefined OS memory pool, which is not fully featured enough to allow dynamic memory allocation and freeing them after completion, if an RTOS

requires that kind of implementation.

For example, the child thread created in ns_test_helpers.c does a simple exit without passing a handle if the memory was dynamically allocated, which is a memory leak scenario.

 

Therefore os_wrapper_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where dynamic memory allocation and freeing is required.

 

               In the current patch we just suspend the child thread and terminate it from parent thread.

 

The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.