Importing the fusefs kernel module?

[Ivan Voras]

On 28 October 2010 20:45, Ulrich Spörlein <uqs at spoerlein.net> wrote:
> On Thu, 28.10.2010 at 12:19:52 +0200, Ivan Voras wrote:
>> 2010/10/28 Gustau Pérez <gperez at entel.upc.edu>:
>>
>> >   The point is, do we stick with fuse or do we switch to puffs ? What is
>>
>> Basically my vote goes to fuse for these reasons:
>>
>>  * More file systems are developed for fuse
>>  * It's more popular both among the users and 3d party software
>> developers (you mentioned Gnome)
>>  * It's better performing, at least in theory, because puffs was not
>> originally written for a multi-threaded kernel (lots of serialization)
>
> I was under the impression, there's a library for puffs (called
> re-fuse?!?) which would provide API compatible shims for FUSE, rendering
> your first argument invalid.
>
> Or am I wrong?

Sort of. According to the development paper at
http://www.netbsd.org/docs/puffs/refuse.pdf the refuse library
doesn't/didn't support the whole FUSE API, and according to a post I
can't seem to find right now (and will send if I find it) the
architectures (especially wrt threading) are too different for it to
be 100% mapping between puffs and fuse. As I'm interested in the more
advanced fuse file systems (e.g. cluster fs's), this stands out as a
possible problem.

The puffs system continued to be developed at NetBSD after the FreeBSD
port was branched. There will also be nontrivial work to merge new
code from NetBSD. I'm not specifically against puffs, but I think
dispersal of efforts between the two APIs is the worst possible
outcome right now.

The above paper also states that there are OpenSolaris and MacOS X
implementations of FUSE which are based on fuse4bsd so there's even
that aspect - they made it stable, why can't we?