Hello all,
for a project, I want to be able to load (elf-)binaries not only from the filesystem, but also from the network (receive binary, then start it.) For this, I will write a L4 app (let's call it "manager" for now) which handles the network part and then tells ned to start the received binary via a special "filename". I already modified ned so that its LUA-interface is exposed to other apps via a capability.
But here comes the first problem: Normally you specify the capability table of a task and an IPC channel in the lua-config file, which ned reads. Ned then prepares the channel and the caps table and starts the task, which then can register the capability. Otherwise, registering fails (the example would do a printf("Could not register my service, is there a 'calc_server' in the caps table?\n");) So... how do I specify which capabilities ned itself can have/register? Currently, I need to have a lua-config which tells ned to start another instance of ned with the required permission to register the capability. But is there any way to avoid having two ned instances and making the first (and only) instance able to register the cap?
Second problem: I found out, that ned (also moe) doesn't start the desired app directly but instead starts the l4re binary (source located in src/l4/pkg/l4re_kernel), passing it the filename of the desired binary. l4re, once started, gets the dataspace of this file and then ultimately starts the app. For my purpose, I would modify l4re_kernel so that if it detects the special "filename" mentioned above, it does not read the file from the filesystem but loads the binary that the "manager" received over the network. To get the data from the manager to the l4re_kernel instance, I thought that a shared dataspace or a shared memory area l4shmc_area_t like in prdocons.c example would be suitable. However, again, both of these things normally require special parameters in the lua config file (as can be seen in the examples), but I have no clue how to do this to l4re_kernel since it is not loaded from such a file, but loaded implicitly each time a new task is started. (so I guess this makes it even harder than the problem with ned since ned is only started once.)
Does anyone have ideas on how to solve these? If someone finds that I phrased this too opaque, please let me know.
Best regards,
Josef Stark
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
for a project, I want to be able to load (elf-)binaries not only from the filesystem, but also from the network (receive binary, then start it.) For this, I will write a L4 app (let's call it "manager" for now) which handles the network part and then tells ned to start the received binary via a special "filename". I already modified ned so that its LUA-interface is exposed to other apps via a capability.
How about this: L4Re provides a virtual file system that you can use to implement your own file systems. Your manager could thereby provide access to networked files through a network file system and would "only" have to implement the Vfs interface for that.
There is an example for a locally implemented temp FS in l4/pkg/tmpfs. In your case your client-local library would call the external manager service, which would then provide file access.
Now your next problem will be to make this new FS known to Ned...
But here comes the first problem: Normally you specify the capability table of a task and an IPC channel in the lua-config file, which ned reads. Ned then prepares the channel and the caps table and starts the task, which then can register the capability. Otherwise, registering fails (the example would do a printf("Could not register my service, is there a 'calc_server' in the caps table?\n");) So... how do I specify which capabilities ned itself can have/register? Currently, I need to have a lua-config which tells ned to start another instance of ned with the required permission to register the capability. But is there any way to avoid having two ned instances and making the first (and only) instance able to register the cap?
Starting a second instance of ned to do that is a reasonable approach.
If you chose the Vfs option, you still need that, because you want to launch your Manager with the initial Ned instance and only the second Ned instance will then be able to access a file system provided by the Manager (that's a bootstrapping problem here).
To tell the second Ned about your new FS, you will have to link it with libmount (l4/pkg/libc_backends/lib/mount) and provide an fstab file during startup in the Lua config as this:
ldr:startv( { caps = {}, log = { "myapp", "red" } }, "rom/myapp", { FSTAB_FILE="rom/myfstab.fstab" });
This lib will then mount the new file system locally into your application (e.g., the second ned instance).
Second problem: I found out, that ned (also moe) doesn't start the desired app directly but instead starts the l4re binary (source located in src/l4/pkg/l4re_kernel), passing it the filename of the desired binary. l4re, once started, gets the dataspace of this file and then ultimately starts the app. For my purpose, I would modify l4re_kernel so that if it detects the special "filename" mentioned above, it does not read the file from the filesystem but loads the binary that the "manager" received over the network.
This might work, but sounds like a hacky solution. With the alternative outlined above you would simply retain the original way of launching programs through the l4re binary. The only difference will be that in your Lua script you launch a binary not as "rom/myapp" but as "net/myapp" and the Vfs will make sure that the respective file requests are then routed to the correct file system implementation.
Does that help you?
Bjoern - -- Dipl.-Inf. Bjoern Doebel Mail: doebel@tudos.org TU Dresden, OS Chair Phone: +49 351 463 38 799 Noethnitzer Str. 46 Fax: +49 351 463 38 284 01187 Dresden, Germany WWW: http://www.tudos.org/~doebel - -- "When the seagulls follow the trawler, it's because they think sardines will be thrown into the sea." (Eric Cantona)
Hey,
first of all, thanks for the quick and thorough answer.
There is an example for a locally implemented temp FS in l4/pkg/tmpfs. In your case your client-local library would call the external manager service, which would then provide file access.
I actually already came across the tmpfs implementation. http://os.inf.tu-dresden.de/pipermail/l4-hackers/2013/005965.html Using this mount command, I could successfully write and read files, even without a fstab file.
To tell the second Ned about your new FS, you will have to link it with libmount (l4/pkg/libc_backends/lib/mount) and provide an fstab file during startup in the Lua config as this:
ldr:startv( { caps = {}, log = { "myapp", "red" } }, "rom/myapp", { FSTAB_FILE="rom/myfstab.fstab" });
This lib will then mount the new file system locally into your application (e.g., the second ned instance).
If I would link ned and manager to the tmpfs lib and used the mount call directly instead of an fstab file, I could avoid having a second ned instance, right?
Your manager could thereby provide access to networked files through a network file system and would "only" have to implement the Vfs interface for that.
Exactly. As a first test, it would be enough, if the manager writes (copies) an executable file to the tmpfs and then instructs ned to launch it.
However, there is a big problem to the tmpfs approach: The same tmpfs is always only visible to the application that mounts it, so if I mount a tmpfs within l4re and manager, both see different filesystems and cannot see each other's files. (probably that's what you meant with "locally"). So if manager writes a temp file to "/tmp/example" and instructs ned to launch "/tmp/example", ned launches l4re, passing "/tmp/example" to it. But l4re then gives an error complaining the file doesn't exist. Even if ned itself creates the temp file, this doesn't help since l4re is a separate task and therefore cannot see the file, again.
This is also mentioned here: http://os.inf.tu-dresden.de/pipermail/l4-hackers/2014/006249.html Given that he says that it is local and there is NO way of accessing the same tmpfs from outside and also that he doesn't hint on how to change that, I assumed that achieving a "global" tmpfs seemed pretty hard. Also I wouldn't know where to begin and abandoned this approach.
This might work, but sounds like a hacky solution.
Somehow true, although I don't think the modifications in the sourcecode wouldn't be too big. Also, I am not exactly experienced with Vfs, so this just might be a much easier solution for me.
With the alternative outlined above you would simply retain the original way of launching programs through the l4re binary.
That's true.
Does that help you?
It does, thank you.
So, I'm still interested in my original question(s), however if you (or anyone) can help me with the tmpfs, I would also appreciate it.
Thanks alot, this mailing list already helped me much.
Cheers,
Josef
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
[..]
If I would link ned and manager to the tmpfs lib and used the mount call directly instead of an fstab file, I could avoid having a second ned instance, right?
I'm not entirely sure.
* As you already found out tmpfs is only local to each application. If you wanted to share an FS between applications, you will have to set up an external server that both programs can access.
* This server needs to be launched by someone. The easy way to set things up imho is to launch the FS server from the first Ned instance and then pass a cap to this FS server to the second Ned instance to be used as an FS.
* I could imagine that you could also do with a single ned instance if you somehow have the FS server notify Ned about its new file system and then Ned calls mount() at this later point in time. Sounds like a circular dependency, though.
Your manager could thereby provide access to networked files through a network file system and would "only" have to implement the Vfs interface for that.
Exactly. As a first test, it would be enough, if the manager writes (copies) an executable file to the tmpfs and then instructs ned to launch it.
However, there is a big problem to the tmpfs approach: The same tmpfs is always only visible to the application that mounts it, so if I mount a tmpfs within l4re and manager, both see different filesystems and cannot see each other's files. (probably that's what you meant with "locally"). So if manager writes a temp file to "/tmp/example" and instructs ned to launch "/tmp/example", ned launches l4re, passing "/tmp/example" to it. But l4re then gives an error complaining the file doesn't exist. Even if ned itself creates the temp file, this doesn't help since l4re is a separate task and therefore cannot see the file, again.
Indeed. [..]
Happy hacking! Bjoern - -- Dipl.-Inf. Bjoern Doebel Mail: doebel@tudos.org TU Dresden, OS Chair Phone: +49 351 463 38 799 Noethnitzer Str. 46 Fax: +49 351 463 38 284 01187 Dresden, Germany WWW: http://www.tudos.org/~doebel - -- "When the seagulls follow the trawler, it's because they think sardines will be thrown into the sea." (Eric Cantona)
- This server needs to be launched by someone. The easy way to set
things up imho is to launch the FS server from the first Ned instance and then pass a cap to this FS server to the second Ned instance to be used as an FS.
Ok, but that still leaves me with the problem that the later-launched l4re instance would also need a cap to this FS server passed to it, which I have no clue how to do. Otherwise it wouldn't have access to the file.
Josef
________________________________________ Von: l4-hackers [l4-hackers-bounces@os.inf.tu-dresden.de]" im Auftrag von "Björn Döbel [doebel@os.inf.tu-dresden.de] Gesendet: Mittwoch, 13. August 2014 12:38 An: l4-hackers@os.inf.tu-dresden.de Betreff: Re: AW: shared dataspace for l4re_kernel/ registering additional caps in ned
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
[..]
If I would link ned and manager to the tmpfs lib and used the mount call directly instead of an fstab file, I could avoid having a second ned instance, right?
I'm not entirely sure.
* As you already found out tmpfs is only local to each application. If you wanted to share an FS between applications, you will have to set up an external server that both programs can access.
* This server needs to be launched by someone. The easy way to set things up imho is to launch the FS server from the first Ned instance and then pass a cap to this FS server to the second Ned instance to be used as an FS.
* I could imagine that you could also do with a single ned instance if you somehow have the FS server notify Ned about its new file system and then Ned calls mount() at this later point in time. Sounds like a circular dependency, though.
Your manager could thereby provide access to networked files through a network file system and would "only" have to implement the Vfs interface for that.
Exactly. As a first test, it would be enough, if the manager writes (copies) an executable file to the tmpfs and then instructs ned to launch it.
However, there is a big problem to the tmpfs approach: The same tmpfs is always only visible to the application that mounts it, so if I mount a tmpfs within l4re and manager, both see different filesystems and cannot see each other's files. (probably that's what you meant with "locally"). So if manager writes a temp file to "/tmp/example" and instructs ned to launch "/tmp/example", ned launches l4re, passing "/tmp/example" to it. But l4re then gives an error complaining the file doesn't exist. Even if ned itself creates the temp file, this doesn't help since l4re is a separate task and therefore cannot see the file, again.
Indeed. [..]
Happy hacking! Bjoern - -- Dipl.-Inf. Bjoern Doebel Mail: doebel@tudos.org TU Dresden, OS Chair Phone: +49 351 463 38 799 Noethnitzer Str. 46 Fax: +49 351 463 38 284 01187 Dresden, Germany WWW: http://www.tudos.org/~doebel - -- "When the seagulls follow the trawler, it's because they think sardines will be thrown into the sea." (Eric Cantona)
_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Hello again Bjoern,
I don't think that I've understood your answers correctly yesterday, so I reread them and now I think I got it. Just to be sure:
The manager uses internally the normal tmpfs implementation. The difference is, that only the manager itself uses tmpfs directly, the other processes which want to access the received files (in this case only l4re, since ned only passes the filename to the l4re binary), access them over a filesystem exported by manager. Therefore, both the manager and l4re see the same files.
There is an example for a locally implemented temp FS in l4/pkg/tmpfs. In your case your client-local library would call the external manager service, which would then provide file access.
So the manager provides IPC calls for accessing the fs. In addition to that, I would need a library, which would a) implement the VFS interface and b) forward all VFS calls to manager (via IPC).
Is that right, so far?
If it is, still a few things seem unclear to me, since I am not exactly familiar with Vfs:
*In case of tmpfs, each application using it needs to either call mount directly or process a fstab file on its own. If I would implement a new Vfs like above, would a single mount suffice? (or: are mount calls in L4Re generally task-local? I think so... otherwise I wouldn't need a library, right?)
*The library would use IPC calls to access files, which means that each task using it would need an appropriate capability/ IPC gate to talk to the server. Is there any way to pass these two things to the l4re binary? Or can the library be done without IPC calls?
Thanks so far, I hope that I got it right this time.
Josef
Hi,
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.
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.
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.)
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.
Cheers,
Josef Stark
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
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.
That's actually good to know!
Out of curiosity: What exactly does l4re do, or why doesn't ned start new tasks directly?
Josef
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Out of curiosity: What exactly does l4re do, or why doesn't ned start new tasks directly?
l4re implements the Region Manager -- this is a thread running inside your application's address space and handling the page faults raised by all other threads.
Bjoern
Everything's working so far! But I have another question... (the actual question is at the bottom)
Here's what I do now: If manager wants to start a received binary, it tells Ned to start "network", e.g. start({caps = {ipc_gate= L4.Env.ipc_gate}},"network"); and Ned then starts - as usual - l4re. l4re then detects the special filename - "network" - and instead of trying to load a file with this filename from ROM (which doesn't exist) it asks manager for the shared dataspace which holds the binary. Since manager may alter the content of the shared dataspace later, l4re copies the shared dataspace and then launches this copy.
So, basically, (in main.cc of l4re_kernel) instead of
file = L4Re_app_model::open_file(Global::l4re_aux->binary);
we do
L4::CapL4Re::Dataspace ds; get_shared_dataspace(ds); //allocation and IPC stuff file=L4Re_app_model::alloc_ds(ds->size()); //this method is now static L4Re_app_model::copy_ds(file,0,ds,0,ds->size());
and then continue with the regular
loader.start(file, Global::local_rm, Global::l4re_aux);
which works.
But my question is, once the task gets killed or finishes, do I need to release/free/unmap the dataspace "file" again (since it is a copy in memory and not a file on ROM) to avoid a resource leak, and, if so, where whould I do this? Or is this done automatically?
Thanks
Josef
On Sat Sep 20, 2014 at 20:45:19 +0000, Stark, Josef wrote:
Everything's working so far! But I have another question... (the actual question is at the bottom)
Here's what I do now: If manager wants to start a received binary, it tells Ned to start "network", e.g. start({caps = {ipc_gate= L4.Env.ipc_gate}},"network"); and Ned then starts
- as usual - l4re. l4re then detects the special filename - "network" - and instead of
trying to load a file with this filename from ROM (which doesn't exist) it asks manager for the shared dataspace which holds the binary. Since manager may alter the content of the shared dataspace later, l4re copies the shared dataspace and then launches this copy.
So, basically, (in main.cc of l4re_kernel) instead of
file = L4Re_app_model::open_file(Global::l4re_aux->binary);
we do
L4::CapL4Re::Dataspace ds; get_shared_dataspace(ds); //allocation and IPC stuff file=L4Re_app_model::alloc_ds(ds->size()); //this method is now static L4Re_app_model::copy_ds(file,0,ds,0,ds->size());
and then continue with the regular
loader.start(file, Global::local_rm, Global::l4re_aux);
which works.
But my question is, once the task gets killed or finishes, do I need to release/free/unmap the dataspace "file" again (since it is a copy in memory and not a file on ROM) to avoid a resource leak, and, if so, where whould I do this? Or is this done automatically?
This will be done automatically. Moe will free resources when all clients are gone.
Adam
Hey, I am currently working on this:
To tell the second Ned about your new FS, you will have to link it with libmount (l4/pkg/libc_backends/lib/mount) and provide an fstab file during startup in the Lua config as this:
ldr:startv( { caps = {}, log = { "myapp", "red" } }, "rom/myapp", { FSTAB_FILE="rom/myfstab.fstab" });
This lib will then mount the new file system locally into your application (e.g., the second ned instance).
Ned doesn't need to know about this filesystem, but my manager application and the l4re thread of the new task do.
Linking and using the manager with libmount works fine.
But I have some problems linking l4re with libmount. Mostly undefined references:
Initially, I tried simply adding libmount to REQUIRES_LIBS of the makefile, but that gave a lot of linker errors. So I replaced most of the minimal lib versions with the full- fledged ones: REQUIRES_LIBS := libc l4re-util libstdc++ libloader \ cxx_libc_io libc_be_minimal_log_io
Without libmount, this also builds fine. But after adding libmount, this leads to undefined references of open, fstat, mount and close. After adding libc_be_l4refile to the list (since it seems to contain the missing symbols), l4re_env_posix_vfs_ops is undefined. And since this is AFAIK only found in libl4re-vfs, I tried adding it, but then the build stops with this error: "src/l4/mk/binary.inc:335: *** Never include 'libl4re-vfs'!. Stop."
So, how can I link l4re (found in pkg/l4re_kernel) successfully with libmount?
Thanks, Josef
To tell the second Ned about your new FS, you will have to link it with libmount (l4/pkg/libc_backends/lib/mount) and provide an fstab file during startup in the Lua config as this:
ldr:startv( { caps = {}, log = { "myapp", "red" } }, "rom/myapp", { FSTAB_FILE="rom/myfstab.fstab" });
This lib will then mount the new file system locally into your application (e.g., the second ned instance).
Ned doesn't need to know about this filesystem, but my manager application and the l4re thread of the new task do.
Linking and using the manager with libmount works fine.
But I have some problems linking l4re with libmount. Mostly undefined references:
Initially, I tried simply adding libmount to REQUIRES_LIBS of the makefile, but that gave a lot of linker errors. So I replaced most of the minimal lib versions with the full- fledged ones: REQUIRES_LIBS := libc l4re-util libstdc++ libloader \ cxx_libc_io libc_be_minimal_log_io
Without libmount, this also builds fine. But after adding libmount, this leads to undefined references of open, fstat, mount and close. After adding libc_be_l4refile to the list (since it seems to contain the missing symbols), l4re_env_posix_vfs_ops is undefined. And since this is AFAIK only found in libl4re-vfs, I tried adding it, but then the build stops with this error: "src/l4/mk/binary.inc:335: *** Never include 'libl4re-vfs'!. Stop."
Ok, so I worked around this error message by removing the sanity check from src/l4/mk/binary.inc; l4re then gets linked with libmount.
I then also linked libl4revfs-fs-l4fs successfully to l4re.
However, whenever I supply a fstab-file to a new task (via FSTAB_FILE=...), mounting with libmount still fails, and the target task then even stops without executing main(). Error displayed: " test | mmap() called without MAP_ANON flag, not supported! test | libmount: Parsing 'rom/fstab' MOE[rm]: unhandled read page fault at 0x0 pc=0xb000eeb4"
Anyway, then I tried to let l4re mount the filesystem without libmount, by inserting mount("none","/tmp","l4fs",0,0); just after the line boot.printf("load binary '%s'\n", Global::l4re_aux->binary);.
However, the mount fails; a perror("mount") after simply yields "mount: Invalid argument". The same mount command however works fine in conventional threads. (Note that a l4fs/libfs-server is running and the needed IPC-Gate has been given to the task. "Normal" tasks/ threads can actually use this server.)
Any ideas how I could convince l4re (l4re_kernel) to mount a libfs/l4fs-type FS?
Thanks in advance, Josef
P.S.: If you view this mail via the mailinglist-archive, the first half of this thread can be found in 2014, since it began there.
Hello again,
I've succeeded a bit since my original question, however it seems that I'm stuck at the same or a related problem I mentioned there. I have not found a solution so far. I'll try to explain it as short as possible:
In my lua config file, I create an IPC gate, and then launch my manager and a second ned instance, passing the IPC gate to both. So now manager can send LUA commands through the IPC gate, which then ned executes. This works so far.
But I also want newly (through manager and second ned) created tasks (or its l4re thread) to be able to talk to manager. For this, I created a second IPC gate in the config and also passed it to manager and ned. Let's call it ipc_gate. If, however, manager then issues e.g. the following LUA call (which creates the new task and passes the IPC-gate capability), the new task is still not able to communicate with manager. "hello = L4.default_loader:start( { caps = { ipc_gate = ipc_gate } }, "rom/hello"); I guess it's because it's another layer and second ned doesn't "know" about the IPC gate which is created in the config file and thereby by first ned, even if I pass the capability to him.
So, is there any way to enable IPC communication between manager and new tasks created by the second ned?
I tried to illustrate it by making a small diagram (it the font messes it up, I've also attached a png image of it). What I need is the ipc line between manager and hello to work.
moe | | (starts) | v ---------------------------------------------------------------------------------- ned | | (executes and starts) | v ------------------------------------config(lua)-----------------------------------
manager <--->ned ^ (ipc) | \ | (ipc) \ | (starts) \ | \ | -------------------------------------------|------------------------------------- v v hello
Thanks in advance!
Josef
Hi,
On Fri Sep 12, 2014 at 11:06:04 +0000, Stark, Josef wrote:
I've succeeded a bit since my original question, however it seems that I'm stuck at the same or a related problem I mentioned there. I have not found a solution so far. I'll try to explain it as short as possible:
In my lua config file, I create an IPC gate, and then launch my manager and a second ned instance, passing the IPC gate to both. So now manager can send LUA commands through the IPC gate, which then ned executes. This works so far.
But I also want newly (through manager and second ned) created tasks (or its l4re thread) to be able to talk to manager. For this, I created a second IPC gate in the config and also passed it to manager and ned. Let's call it ipc_gate. If, however, manager then issues e.g. the following LUA call (which creates the new task and passes the IPC-gate capability), the new task is still not able to communicate with manager. "hello = L4.default_loader:start( { caps = { ipc_gate = ipc_gate } }, "rom/hello"); I guess it's because it's another layer and second ned doesn't "know" about the IPC gate which is created in the config file and thereby by first ned, even if I pass the capability to him.
So, is there any way to enable IPC communication between manager and new tasks created by the second ned?
If I understand correctly, I think you need to write caps = { ipc_gate = L4.Env.ipc_gate }
L4.Env.ipc_gate is the cap given to the second ned by the first one, so it's in its environment.
I tried to illustrate it by making a small diagram (it the font messes it up, I've also attached a png image of it). What I need is the ipc line between manager and hello to work.
Thanks, that helped!
Adam
l4-hackers@os.inf.tu-dresden.de