First version

README

@@ -0,0 +1,88 @@
+This is a Mono/.NET binding for FUSE.
+
+Short HOWTO:
+
+Within one terminal:
+	sudo /sbin/modprobe fuse  # need FUSE kernel module to use.
+	./configure
+	make
+	cd example/HelloFS
+	mkdir t
+	./hellofs t
+
+Within another terminal
+	cd example/HelloFS
+	ls t
+	cat t/hello
+
+This should display files controlled by HelloFS.exe.
+
+To unmount the filesystem, you need to use the `fusermount' program:
+	cd example/HelloFS
+	fusermount -u t
+
+KILLING THE FUSE PROGRAM IS NOT ENOUGH.  The program will die, but 
+FUSE and the kernel will still think that the directory is mounted.
+Result: you can't remount the directory, and trying to do anything
+with it will result in IO errors.
+
+For full trace output, set the MONO_TRACE_LISTENER environment 
+variable and add the -odebug command-line argument:
+
+	cd example/HelloFS
+	MONO_TRACE_LISTENER=Console.Out### ./hellofs -odebug t
+
+MONO_TRACE_LISTENER controls the Mono.Fuse trace output, while 
+-odebug controls the libfuse-generated trace output.
+
+`hellofs' also takes its own command-line aruments.  By default, 
+it exports two files, `data' and `hello'.  `hello' contains the 
+string "Hello World!", while `data' is a 100 MB (base 10) file that 
+generates its content on-demand.
+
+If you pass the --data.im-in-memory flag, a `data.im' file will be 
+available which is a 100MB (base 10) file with the same contents as 
+`data', but it is backed by a 100MB byte[] instead of generating its 
+contents on demand:
+
+	cd example/HelloFS
+	./hellofs --data.im-in-memory t
+
+The 100MB byte[] is allocated the first time the contents of 
+`data.im' are read.
+
+`data.im' is useful to see the difference in performance between
+generate-on-demand and cached behaviors:
+
+	cd example/HelloFS
+	./hellofs --data.im-in-memory t
+
+	# On-demand copy
+	time cp t/data f.txt
+		real    0m8.469s
+		user    0m0.020s
+		sys     0m1.128s
+	
+	# In-memory copy
+	# Note that the first `data.im' access is longer
+	# because it needed to allocate the array.
+	# Subsequent calls are shorter:
+	time \cp -f t/data.im f.txt
+		real    0m12.393s
+		user    0m0.004s
+		sys     0m1.172s
+	time \cp -f t/data.im f.txt
+		real    0m5.233s
+		user    0m0.016s
+		sys     0m1.136s
+	
+	# And for comparison, cp without FUSE:
+	time cp f.txt f2.txt
+		real    0m10.252s
+		user    0m0.016s
+		sys     0m1.000s
+
+And yes, on my machine it's faster to go through FUSE than to go 
+through the filesystem (though usually the filesystem outperforms 
+the on-demand generation).  My machine is probably misconfigured. :-/
+Your mileage will vary.