Re: Support for kernel and lowlevel FUSE API

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Fri Aug 06 2010 at 16:57:03 +0000, Emmanuel Dreyfus wrote:
> - There is a daemon called perfused (PUFFS Enabled Relay to FUSE, 
> of course), which opens a /dev/fuse socket and wait for filesystems
> to connect there. It will relay kernel requests to the filesystem, 
> and filesystems replies to the kernel.
> 
> - The filesystem needs a minor modification: it needs to call 
> perfuse_mount() instead of mount(). perfuse_mount() sends a message
> through /dev/fuse to perfused, and perfused does the actual mount. 
> I implemented perfuse_mount() in a single-function library (libperfuse).

Just to clarify: "the filesystem" means one using /dev/fuse directly, yes?

> Most of the time, the filesystem does the mount() through libfuse or
> usermount(1), therefore we have many situation where a filesystem can
> be used unmodified, provided libfuse and/or usermount have been patched.

As stated in private email, I think most of the time it makes sense
to run perfused "inline" in the file server instead of requiring a
separate daemon.  This brings down the number of moving parts and I
assume simplifies e.g. permissions.

> Now the big question: should libperfuse and perfused be imported in-tree.
> pooka@ think they should, as any modification in the VFS should be
> quickly reflected there. 
> 
> On the other hand, perfused just implements the kernel level APIi, and
> many programs use the libfuse low level API. In order to support
> theses programs, we may also want import libfuse. I am not sure everyone
> would enjoy the idea.
> 
> Any opinions on what should go in tree?

To restate my opinion:

background:
Like I have mentioned earlier, thanks to FUSE there is no need to keep
the puffs api stable and it will follow the kernel VFS quite intimately
to maximize performance and minimize translation headache.

This means the api will change, and anything maintained outside the tree
will most likely come down with a case of severe ifdefitis.  Therefore,
anything using the puffs api should be in base.

A very important detail is being able to test changes without having
to install 3rd party software.  Luckily, test programs can be written
directly against the /dev/fuse API.  I encourage you to start building
the test set from every "evil oneliner" problem you fix.  I now seriously
regret not doing this for puffs back when I was writing it.

As long as we don't have any in-tree file servers using the low level
APIs, I don't see any reason to import libfuse into base and would simply
offer a perfuse "inline" patched version for NetBSD from pkgsrc.

So in summary, do it like coda, except supply in-tree tests to make the
lives of people who may need to touch it in rototills simple.

my proposal:

perfuse: in-tree
atf tests for perfuse: in-tree
libfuse: pkgsrc
file servers: pkgsrc