Hello Samuel,

* Samuel Hall <sammy.hall@...381...> [2016-01-25 00:54:06 +0100]:

In the implementation described in the article VFS isn't used due to the fact, that VFS wasn't available in genode at that time. A comment of the libc_fuse plugin states:

[…]

So does the current implementation, when using a FUSE fs via the libc plugin, require VFS?

Yes. If you look at the different FUSE file systems you will see that all of them use '/dev/blkdev' [1] to access the block device. By now, this block device is configured through the VFS configuration by using the VFS block plugin, e.g.:

<libc ...> <vfs> ... <dir name="dev"> <block name="blkdev"/> </dir> </vfs> </libc>

So when the FUSE file system wants to access the block device, the libc will query all its plugins and normally the VFS plugin will answer the call.

[1] repos/libports/src/lib/fuse-ext2/init.cc:49

Is there any more detailed information about the VFS in genode?

There is more information in the release notes, albeit somewhat scattered.

I am particularly interested in finding out how the flow of a FUSE call differs in genode compared to the "normal" call as shown in this graphic [1].

If your component uses libc_fuse it looks basically like this:

open(/foo) ↳ libc (plugin list) ↳ libc_fuse (plugin) ↳ fuse->op.open(/foo) ↳ “ext2_read_inode” …

Since this happens all in the component itself there is no context switch necessary (however, a context switch might occur in the FUSE file system backend if the block session is provided by another component).

When using a FUSE based fs as a file system server as described in Josef's response, do any adjustments have to be made to the FUSE fs so it runs on genode?

It depends on the file system but generally speaking one mostly ends up reimplementating the file systems main() function if it uses the normal fuse event loop.

Regards Josef