Mono.Fuse is a binding for the FUSE library, permitting user-space file systems to be written in C#.
Why? === I read Robert Love's announcement of beaglefs, a FUSE program that exposes Beagle searches as a filesystem. My first thought: Why wasn't that done in C# (considering that the rest of Beagle is C#)? What about SULF? =============== Stackable User-Level Filesystem, or SULF (http://arg0.net/users/vgough/sulf/), is a pre-existing FUSE binding in C#, started by Valient Gough in 2004. It has since been replaced by fusewrapper, http://arg0.net/darcs/fusewrapper. Mono.Fuse has no relation to SULF or fusewrapper, for two reasons: 1. It goes to great efforts to avoid a Mono.Posix.dll dependency, duplicating Mono.Unix.Native.Stat (Fuse.Stat), Mono.Unix.Native.Statvfs (Fuse.StatFS), and many methods from Mono.Unix.Native.Syscall (Fuse.Wrapper). 2. I don't like the SULF API. (Not that I spent a great deal of time looking at it, but what I did see I didn't like.) SULF is an inode-based API, while Mono.Fuse is a path-based API. I think paths are easier to deal with, and Valient Gough believes inodes are. 3. SULF wraps the FUSE kernel-level interface, while Mono.Fuse wraps the higher level libfuse C interface I find (1) the most appalling, if only because I'm the Mono.Posix maintainer and I'd like to see my work actually used. :-) Once I started writing Mono.Fuse, I discovered a good reason to avoid Mono.Posix: it's currently impossible to use from outside of Mono. I figured this would be a good opportunity to rectify that, making it easier for additional libraries to build upon the Mono.Posix infrastructure. Implementation: ============== Mono.Fuse requires patches to the mcs, mono, and mono-tools modules, changes which need to be proposed and discussed. mcs: --- There are two major changes: * The addition of several new methods public to Mono.Unix.Native.NativeConvert: class Mono.Unix.Native.NativeConvert { public static bool TryCopy (ref Flock source, IntPtr destination); public static void Copy (ref Flock source, IntPtr destination); public static bool TryCopy (IntPtr source, out Flock destination); public static void Copy (IntPtr source, out Flock source); /* repeat for most other structure types, e.g. Stat, Statvfs, Pollfd, Timeval, Timezone, Utimbuf... */ } * class/Mono.Posix/Mono.Unix.Native/make-map.cs has been moved to mono-tools/create-native-map/src/create-native-map.cs. Those are the "public" changes. Internally, MapAttribute has been revamped considerably, as has create-native-map.exe, but MapAttribute remains an internal attribute and is not part of the public API. The new methods on NativeConvert are required to permit extending the current Mono.Posix infrastructure, so that Mono.Fuse can make use of Mono.Posix's Stat & Statvfs structure copying support (among other types). Statvfs is particularly nice, as mono/support/sys-statvfs.c is a #ifdef-infested scourge, largely by trying to support Linux (statvfs) and OS X/*BSD (statfs) and make them look identical to managed code. mono: ---- create-native-map.exe now has support to generate structure declarations, to better ensure that managed & native structures are identical (as opposed to doing this by hand). map-icalls.h has been removed, its contents inserted into map.h. map.c and map.h have additional methods for copying structures between managed & native representations, e.g. Mono_Posix_ToStat (native->managed) and Mono_Posix_FromStat (managed->native). Many of the .c files have been changed to update their prototypes to match the current create-native-map-generated declarations in map.h, and to remove the hand-created structure definitions (as create-native-map.exe generates these now). A cached version of create-native-map.exe is now kept as mono/support/create-native-map.exe, so that mono-tools isn't required to run `make refresh'. The `update-cnm' target updates the cached program. Otherwise, no public API changes or additions (since MonoPosixHelper is considered to be an internal API, any changes aren't public). mono-tools: ---------- Adds create-native-map.exe, and adds a create-native-map.pc file so that pkg-config can be used to update a cached copy of create-native-map.exe & MapAttribute.cs. HOWTO: ===== Go to http://www.jprl.com/mono-fuse for the patches and source download. Apply ``mcs.patch'' to a ``mcs'' checkout, rebuild, and install. Apply ``mono.patch'' to a ``mono'' checkout, rebuild, and install. Build ``mono-fuse-0.2.0.tar.gz'' in "the standard manner". Optionally, apply ``mono-tools.patch'' to a ``mono-tools'' checkout, rebuild, and install. Questions: ========= - How should we cope with unstable APIs which make use of native code? The Application Deployment Guidelines [1] don't address this issue. For example, the Guidelines stat that apps using an unstable API should have a cached copy of the unstable assembly (and use pkg-config to get that copy). This works for Mono.Fuse.dll, but what should be done for libMonoFuseHelper.so? This can't realistically be copied into their app. Perhaps the Egg model should be followed? [1] http://www.mono-project.com/Guidelines:Application_Deployment#Libraries_with_Unstable_APIs # vim: et tw=70 _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
