I've responded separately to Jon because I find his comments inflammatory. The SULF project you reference predates the FUSE low-level API and even the latest couple kernel interface revisions. You could have found out about much newer code, and perhaps learned something about FUSE itself through a number of routes:
1. ask about the state of SULF. I would not have recommended starting with this defunct project, nor recommended referencing it as an alternative. 2. search FUSE mailing list for C# related announcements (and language binding discussions in general) 3. search this Mono list for FUSE related announcements regards, Valient On 8/29/06, Jonathan Pryor <[EMAIL PROTECTED]> wrote: > 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. > > Mono.Fuse has no relation to SULF, 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.) > > 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 modules, changes which > need to be proposed (hence this email) and discussed. > > mono: > ---- > > The biggest problem with the mono module is that no headers are > installed, making it difficult to make use of libMonoPosixHelper.so. > > Changes: > - Modify `configure' to generate a mono-config.h file, installed as > $libdir/mono/include/mono-config.h. (Basic idea "borrowed" from > GLib's $libdir/glib-2.0/include/glibconfig.h). > - Add a mono-posix-helper.pc file > - Install the files $includedir/mono/posix/helper.h and > $includedir/mono/posix/map.h. > > map.h is the current map.h file generated by make-map.exe, with some > major additions (detailed in the mcs section). > > helper.h is the main include file, which includes map.h and declares > all types/functions which cannot be generated by make-map.exe. > > mono-config.h is necessary because it needs to contain > platform-specific macros. In particular, Linux needs: > > int > Mono_Posix_ToStat (struct statvfs *to, struct Mono_Posix_Helper *to); > > while OS X and *BSD need: > > int > Mono_Posix_ToStat (struct statfs *to, struct Mono_Posix_Helper *to); > > Note `struct statvfs' vs. `struct statfs'. The mono/posix/helper.h > header needs to "paper over" the difference, and thus needs to know > which type the platform prefers. helper.h thus looks like: > > #ifdef MONO_HAVE_STATVFS > struct statvfs; > int Mono_Posix_ToStatvfs (struct statvfs *from, > struct Mono_Posix_Statvfs *to); > #endif > #ifdef MONO_HAVE_STATFS > struct statfs; > int Mono_Posix_ToStatvfs (struct statfs *from, > struct Mono_Posix_Statvfs *to); > #endif > > One of MONO_HAVE_STATVFS or MONO_HAVE_STATFS would be defined in > mono-config.h. > > > mcs: > --- > > There are two major changes: > > * The addition of one public attributes to the API: > > // targets Class, Delegate, Enum, Field, Struct > class Mono.Unix.Native.MapAttribute { > public MapAttribute (); > public MapAttribute (string nativeType); > public string NativeType {get;} > public string NativeSymbolPrefix {get; set;} > } > > * A major revamp to make-map.exe > > The Map and MapHeader attributes are public so that make-map.exe can > use a publically exposed API for code generation purposes which can be > used by other libraries (Mono.Fuse makes use of these changes). > > Make-map.exe can also generate structure declarations and delegate > declarations in addition to P/Invoke function declarations, > allowing for a better, automated interface between C and C#. > > Previously, [Map] could only be used on enumerations. > > Now, [Map] can be used on classes, structures, & delegates, to create > a C declaration of the C# type, suitable for P/Invoke purposes, e.g. > > [Map] struct Stat {public FilePermissions mode;} > > would generate the C declaration > > struct Namespace_Stat {unsigned int mode;}; > > The MapAttribute.NativeType property is used to specify that type > conversion functions should be generated, thus: > > [Map ("struct stat")] struct Stat {public FilePermissions mode;} > > would generate > > struct Namespace_Stat {unsigned int mode;}; > int Namespace_ToStat (struct stat *from, struct Namespace_Stat *to); > int Namespace_FromStat (struct Namespace_Stat *from, struct stat *to); > > along with the actual implementations of Namespace_ToStat() and > Namespace_FromStat(). > > The MapAttribute.NativeSymbolPrefix is used to specify the C > "namespace" to use: > > [Map (NativeSymbolPrefix="Foo")] struct Stat {FilePermissiond mode;} > > generates > > struct Foo_Stat {unsigned int mode;}; > > This prefix is also used for the conversion functions. > > (You may be wondering why NativeSymbolPrefix exists at all. This is > for reasonable symbol versioning -- make-map.exe currently has a > "hack" in place to rename Mono.Unix(.Native) to Mono_Posix, a hack > I'd like to remove, and NativeSymbolPrefix allows the Mono.Unix.Native > types to have a "Mono_Posix" C namespace in a reasonably general > manner.) > > The previously internal Mono.Unix.HeaderAttribute has been removed. > The HeaderAttribute.Includes and HeaderAttribute.Defines properties > have been replaced with make-map.exe command-line arguments. In > particular, HeaderAttribute.Includes has been replaced with > --autoconf-header, --impl-header, --impl-macro, --public-header, and > --public-macro (the first three modify the generated .c file, while > the latter two modify the generated .h file). > > Finally, make-map.exe has been renamed and moved from > mcs/class/Mono.Posix/Mono.Unix.Native/make-map.exe to > mcs/tools/create-native-map/create-native-map.exe. > > > 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.1.0.tar.gz'' in "the standard manner" (ye olde > "./configure; make; make install" business). > > > Questions: > ========= > > - Is it OK for create-native-map.exe to be a .NET 2.0 app? > > - How should we cope with unstable APIs which make use of native > code? The Application Deployment Guidelines [1] don't address > this issue, nor the related issue of what should be done with > 64-bit binaries. In particular, for an AMD64 machine, which > directory layout should be used for an assembly + native lib > combo? > 1. What Mono seems to do, with the GAC in $prefix/lib no matter > what the architecture: > > /usr/lib/mono-fuse/Mono.Fuse.dll > /usr/lib64/libMonoFuseHelper.so > 2. Be consistent, and toss everything in @libdir@: > > /usr/lib64/mono-fuse/Mono.Fuse.dll > /usr/lib64/libMonoFuseHelper.so > > [1] > http://www.mono-project.com/Guidelines:Application_Deployment#Libraries_with_Unstable_APIs > > Thanks, > - Jon > > > _______________________________________________ > Mono-list maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/mono-list > _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
