AW: shared dataspace for l4re_kernel/ registering additional caps in ned
j.stark at tum.de
Wed Aug 13 13:00:41 CEST 2014
>* 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.
Von: l4-hackers [l4-hackers-bounces at os.inf.tu-dresden.de]" im Auftrag von "Björn Döbel [doebel at os.inf.tu-dresden.de]
Gesendet: Mittwoch, 13. August 2014 12:38
An: l4-hackers at os.inf.tu-dresden.de
Betreff: Re: AW: shared dataspace for l4re_kernel/ registering additional caps in ned
-----BEGIN PGP SIGNED MESSAGE-----
> 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.
Dipl.-Inf. Bjoern Doebel Mail: doebel at 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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
-----END PGP SIGNATURE-----
l4-hackers mailing list
l4-hackers at os.inf.tu-dresden.de
More information about the l4-hackers