Josef Söntgen josef.soentgen at ...1...
Wed Jan 27 18:55:09 CET 2016

Hello Samuel,

* Samuel Hall <sammy.hall at ...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 ...>
      <dir name="dev"> <block name="blkdev"/> </dir>

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

[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

> 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:

  ↳ 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.


More information about the users mailing list