AW: shared dataspace for l4re_kernel/ registering additional caps in ned

[Stark, Josef]

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