Background:
Azure RTOS aka ThreadX has a feature, called "modules", that takes advantage of the CPU's memory protection unit / memory management unit (MPU or MMU used in MPU mode), and which allows for separate applications (aka modules) to be loaded / unloaded at runtime.
Each application is isolated from other applications and from the ThreadX kernel. Applications run in a less privileged mode compared to the ThreadX kernel. When an application calls a ThreadX API, e.g., tx_thread_create(), that actually translates (via macro...) to a call into txm_thrad_create(), which first switches to a higher CPU privilege mode before calling the actual implementation, _tx_thread_create().
Question:
what's the right way of using/integrating TCP/IP network stack which is part of Azure ROTS, aka NetX / NetXDuo, in this case?
Would the NetX TCP/IP stack (along with any addons that the application might need such as mqtt, azure_iot, websocket, etc. etc.) be part of the application, or part of the "Kernel". It's not immediately clear what the creators of ThreadX / NetX have envisioned.
If part of the application, it means every application (i.e. module) would contain its own copy of the network stack. Even if we are OK w/ the resulting inefficiency, it's not even clear how that would work. What if 2 applications both want to use the network stack on the same ethernet port?
On the other hand, if the network stack is part of the Kernel, then are we expected to implement the switch to kernel mode ourselves? In ThreadX, one automatically gets the txm_xyz() versions of all the tx_xyz() APIs when the "modules" feature is enabled. There are no nxm_xyz() versions of the NetX nx_xyz() APIs.... There are many many nx_xyz() APIs...
Thoughts?