From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
From: "Russ Cox" <rsc@swtch.com>
Date: Mon, 23 Jan 2006 12:06:09 -0500
Message-Id: <20060123170614.07D331E8C37@holo.morphisms.net>
Subject: [9fans] fuse bashing
Topicbox-Message-UUID: e3f7edbc-ead0-11e9-9d60-3106f5b1d025

Fuse has a nice crunchy layer of GNU crud around it
which makes it hard to swallow, but at its core, it's
very close to 9P (or the version 8 network file system).

You open /dev/fuse, hand the fd to the kernel to mount
it somewhere, and then you read and write fuse messages
on the fd.  All the kernel vfs operations end up as fuse 
messages, including close.  (It just isn't used in examples,
but it does exist.  It's called release.)  The main failing I see
from a protocol standpoint seems to be the lack of a flush
message.  Instead, fuse just puts interrupted requests on
a list and assumes they'll come back eventually.  
This wouldn't be appropriate for things like interrupting
a read from /dev/tty.  For mounting file systems on a 
Unix system, fuse is probably a better protocol than 9P.
It appears to match the kernel better, so the implementation
should be simpler.  (As soon as you want to talk between
different operating systems or send the messages over
the network, that's where 9P starts to make more sense.)

Fuse's main problem is that they bundle the protocol inside
the library loop, so what you see from the outside is the
equivalent of 9P+lib9p.  You don't ever get to see the protocol
by itself.  That's often good enough, but sometimes it's nice
to deal with the raw messages.  Another big problem with
fuse is the lack of easily-found documentation.  

If you download a fuse distribution and look in
kernel/fuse_kernel.h you can see the messages.

Russ