Re: AW: shared dataspace for l4re_kernel/ registering additional caps in ned
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 ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: AW: shared dataspace for l4re_kernel/ registering additional caps in ned
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 ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: AW: shared dataspace for l4re_kernel/ registering additional caps in ned
>* 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 [[email protected]]" im Auftrag von "Björn Döbel [[email protected]] Gesendet: Mittwoch, 13. August 2014 12:38 An: [email protected] 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 DoebelMail: [email protected] TU Dresden, OS ChairPhone: +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) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlPrPwwACgkQP5ijxgQLUNl4BgCglmFMOOUPHyQt7q28/5Gn3NP+ TH0AoIeoSPUI277LsiZZXM9gm36Mv5xr =cQIz -END PGP SIGNATURE- ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
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 DoebelMail: [email protected] TU Dresden, OS ChairPhone: +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) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlPrPwwACgkQP5ijxgQLUNl4BgCglmFMOOUPHyQt7q28/5Gn3NP+ TH0AoIeoSPUI277LsiZZXM9gm36Mv5xr =cQIz -END PGP SIGNATURE- ___ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
