[Mono-dev] Announce: Mono.Fuse 0.2.0 (+ Required mcs & mono patches)

Jonathan Pryor jonpryor at vt.edu
Fri Sep 1 07:43:15 EDT 2006


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





More information about the Mono-devel-list mailing list