On 08/10/2016 04:31 PM, ba_f wrote:
Am 2016-08-08 23:51, schrieb Adam Lackorzynski:
On Mon Aug 08, 2016 at 12:32:02 +0200, ba_f wrote:
Am 2016-08-05 15:08, schrieb Matthias Lange:
Hi,
On 08/04/2016 03:05 PM, ba_f wrote:
But, is it also possible to do some configuration during run-time
[...]
Ok, I see it's not possible. But, maybe I can take the chance for a deeper understanding.
This is how I understand things, now. Please, correct me if I'm wrong:
1.) Moe starts first, followed by Ned.
Ned is started by moe.
2.) Ned parses lua.cfg and, on 'new_channel()' it creates a new IPC-Gate with l4_msgtag_t l4_factory_create_gate( l4_cap_idx_t factory, l4_cap_idx_t target_cap, l4_cap_idx_t thread_cap, l4_umword_t label).
Yes, this is done via the Lua bindings (see ned.lua).
3.) The IPC-Gate is a Kernel-Object and thus stored into the Kernel. (Does Moe help here?)
No, moe is not involved here.
'thread_cap' is stored/pushed into the servers capability table and 'target_cap' is for the client task, aren't they?
'target_cap' is mapped with the appropriate rights into the new task's capability table. That means it can be mapped with server rights into the server task and with read/write rights into the client task. 'thread_cap' is not used.
4.) With l4re_env_get_cap() client & server look for a matching capability in their own cap-tables.
Yes. Client and server use their local name to lookup the capability.
If I got it right, any Task can create an IPC-Gate at run-time and thus create child tasks with ipc-server or ipc-client capabilities, don't they?
That depends on the task's factory but the general answer is yes.
Matthias.