fix

ChangeLog

@@ -1,3 +1,9 @@
+2004-09-01  Miklos Szeredi <miklos@szeredi.hu>
+
+	* Add -D_REENTRANT to the compile flags
+
+	* Add documentation of fuse internals by Terje Oseberg
+ 
 2004-08-16  Miklos Szeredi <miklos@szeredi.hu>
 
 	* Change release method to be non-interruptible.  Fixes bug

Filesystems

@@ -185,3 +185,17 @@ Description:
   bayesian classification, are added through plugins.
 
 ==============================================================================
+Name: GmailFS
+
+Author: Richard Jones <richard (at) jones (dot) name>
+
+Homepage: http://richard.jones.name/google-hacks/gmail-filesystem/gmail-filesystem.html
+
+Description:
+
+  GmailFS provides a mountable Linux filesystem which uses your Gmail
+  account as its storage medium. GmailFS is a Python application and
+  uses the FUSE userland filesystem infrastructure to help provide the
+  filesystem, and libgmail to communicate with Gmail.
+
+==============================================================================

configure.in

@@ -19,7 +19,7 @@ if test -z "$mkdir_p"; then
 fi
 
 CFLAGS="-Wall -W -g -O2"
-CPPFLAGS="$CPPFLAGS -D_FILE_OFFSET_BITS=64"
+CPPFLAGS="$CPPFLAGS -D_FILE_OFFSET_BITS=64 -D_REENTRANT"
 
 AC_ARG_ENABLE(kernel-module,
 	[  --enable-kernel-module  Compile kernel module, requires --with-kernel option ])

doc/how-fuse-works

@@ -0,0 +1,54 @@
+                           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, 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 /proc/fs/fuse/dev and send the file
+handle over a UNIX domain socket back to fuse_mount().
+
+fuse_mount() returns the filehandle for /proc/fs/fuse/dev 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 /proc/fs/fuse/dev, 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
+/proc/fs/fuse/dev 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 /proc/fs/fuse/dev. 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().