FUSE + VFS

[Josef Söntgen]

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