Various documentation updates

Move README.NFS into doc/
Update project URL
Remove reference to non-existent INSTALL file
Remove outdated/obsolete NEWS and how-fuse-works files.
Update references to examples.

4 files changed, 35 insertions, 56 deletions

diff --git a/doc/Makefile.am b/doc/Makefile.am
index 2f2fa0f..1644383 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -2,4 +2,4 @@
 
 dist_man_MANS = fusermount.1 mount.fuse.8
 
-EXTRA_DIST = how-fuse-works kernel.txt Doxyfile html
+EXTRA_DIST = kernel.txt Doxyfile html README.NFS developer-notes.rst
diff --git a/doc/README.NFS b/doc/README.NFS
new file mode 100644
index 0000000..f3348d5
--- /dev/null
+++ b/doc/README.NFS
@@ -0,0 +1,33 @@
+NFS exporting is supported in Linux kernels 2.6.27 or later.
+
+You need to add an fsid=NNN option to /etc/exports to make exporting a
+FUSE directory work.
+
+Filesystem support
+------------------
+
+NFS exporting works to some extent on all fuse filesystems, but not
+perfectly.  This is due to the stateless nature of the protocol, the
+server has no way of knowing whether the client is keeping a reference
+to a file or not, and hence that file may be removed from the server's
+cache.  In that case there has to be a way to look up that object
+using the inode number, otherwise an ESTALE error will be returned.
+
+1) low-level interface
+
+Filesystems need to implement special lookups for the names "." and
+"..".  The former may be requested on any inode, including
+non-directories, while the latter is only requested for directories.
+Otherwise these special lookups should behave identically to ordinary
+lookups.
+
+2) high-level interface
+
+Because the high-level interface is path based, it is not possible to
+delegate looking up by inode to the filesystem.
+
+To work around this, currently a "noforget" option is provided, which
+makes the library remember nodes forever.  This will make the NFS
+server happy, but also results in an ever growing memory footprint for
+the filesystem.  For this reason if the filesystem is large (or the
+memory is small), then this option is not recommended.
diff --git a/doc/how-fuse-works b/doc/how-fuse-works
deleted file mode 100644
index a5febe3..0000000
--- a/doc/how-fuse-works
+++ /dev/null
@@ -1,54 +0,0 @@
-                           How Fuse-1.3 Works
-
-[Written by Terje Oseberg]
-
-1. The fuse library.
-
-When your user mode program calls fuse_main() (lib/helper.c),
-fuse_main() parses the arguments passed to your user mode program,
-then calls fuse_mount() (lib/mount.c).
-
-fuse_mount() creates a UNIX domain socket pair, then forks and execs
-fusermount (util/fusermount.c) passing it one end of the socket in the
-FUSE_COMMFD_ENV environment variable.
-
-fusermount (util/fusermount.c) makes sure that the fuse module is
-loaded. fusermount then open /dev/fuse and send the file handle over a
-UNIX domain socket back to fuse_mount().
-
-fuse_mount() returns the filehandle for /dev/fuse to fuse_main().
-
-fuse_main() calls fuse_new() (lib/fuse.c) which allocates the struct
-fuse datastructure that stores and maintains a cached image of the
-filesystem data.
-
-Lastly, fuse_main() calls either fuse_loop() (lib/fuse.c) or
-fuse_loop_mt() (lib/fuse_mt.c) which both start to read the filesystem
-system calls from the /dev/fuse, call the usermode functions
-stored in struct fuse_operations datastructure before calling
-fuse_main(). The results of those calls are then written back to the
-/dev/fuse file where they can be forwarded back to the system
-calls.
-
-2. The kernel module.
-
-The kernel module consists of two parts. First the proc filesystem
-component in kernel/dev.c -and second the filesystem system calls
-kernel/file.c, kernel/inode.c, and kernel/dir.c
-
-All the system calls in kernel/file.c, kernel/inode.c, and
-kernel/dir.c make calls to either request_send(),
-request_send_noreply(), or request_send_nonblock(). Most of the calls
-(all but 2) are to request_send(). request_send() adds the request to,
-"list of requests" structure (fc->pending), then waits for a response.
-request_send_noreply() and request_send_nonblock() are both similar in
-function to request_send() except that one is non-blocking, and the
-other does not respond with a reply.
-
-The proc filesystem component in kernel/dev.c responds to file io
-requests to the file /dev/fuse. fuse_dev_read() handles the
-file reads and returns commands from the "list of requests" structure
-to the calling program. fuse_dev_write() handles file writes and takes
-the data written and places them into the req->out datastructure where
-they can be returned to the system call through the "list of requests"
-structure and request_send().
diff --git a/doc/kernel.txt b/doc/kernel.txt
index 397a41a..fd3f174 100644
--- a/doc/kernel.txt
+++ b/doc/kernel.txt
@@ -49,7 +49,7 @@ using the sftp protocol.
 The userspace library and utilities are available from the FUSE
 homepage:
 
-  http://fuse.sourceforge.net/
+  https://github.com/libfuse/libfuse/
 
 Filesystem type
 ~~~~~~~~~~~~~~~