matthias.lange at kernkonzept.com
Thu Aug 11 09:07:21 CEST 2016
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:
>>>> On 08/04/2016 03:05 PM, ba_f wrote:
>>>>> But, is it also possible to do some configuration during
> 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
> 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
'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.
More information about the l4-hackers