Some comments only.
On Sun Aug 17, 2014 at 11:03:07 +0000, Stark, Josef wrote:
in case anyone else is interested, here's what I found out so far: So, as mentioned earlier, if ned wants to launch a certain task you specified, ned does so indirectly by launching l4re and passing the name of the target binary to l4re, so l4re is basically the "parent" of the target task.
Parent maybe but not in the sense of a task because l4re runs in the very same task as the application.
As a parent, it seems that it receives all the capabilities you specified in your lua config for the target task, so doing IPC between l4re and _another_ task seems much easier than expected.
It's just because they share the same task.
I could successfully share a dataspace between a third task and l4re. I used the config file from the shared_ds example, changed the client sourcecode so that it only printed a "Hello" and then slept forever. The part where it accesses the dataspace from the server was moved (the part where it changes the ds content again was left out since I did not need it) into l4re_kernel (the l4re binary), but is only triggered if the name of the target binary was "ds_clnt", so that this code wasn't executed multiple times (I know, this is _very_ hacky, but remember, it should only serve as an example).
And indeed, now l4re itself was able to print the content of the dataspace. (Accessing the ds from both l4re and its child also works, although this wasn't my intention and I don't need it.)
Ok, good but no suprise either :)
Instead of sharing a dataspace it should also be possible to do normal IPC calls between l4re and a third task, e.g. to implement a central temporary filesystem (which then can also be accessed from within l4re) like mentioned in a previous mail.
Yes. Basically, as you found out, with shared memory any thread/task that has access to this memory can access it and exchange data.
Adam