AW: shared dataspace for l4re_kernel/ registering additional caps in ned
j.stark at tum.de
Thu Aug 14 12:55:42 CEST 2014
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.
More information about the l4-hackers