[Mono-dev] Announce: Mono.Fuse (+ Required Mono.Posix Changes)

[Paolo Molaro]

On 08/30/06 Jonathan Pryor wrote:
> I'm not entirely sure I see the "compatibility nightmare."  Nor do I see
> the "million reasons."  The only reasons I can think of is that there
> are some symbols which should be removed (e.g. the old Mono.Posix
> namespace functions such as "wifexited" and "helper_Mono_Posix_Stat").

As I said, none of the functions, structures, data type and preprocessor symbols
defined in the binary MonoPosixHelper shared library and in its private
header files are designed for public consumption. If you count them up
there won't be millions, but still likely thousands:)
None of that will be exported for public use: it's just an internal
implementation detail.

> Con:
>   - Requires more P/Invoke transitions.
>     - One P/Invoke transition to call NativeConvert.FromErrno
>       (done for each delegate invoked).
>     - One P/Invoke transition for each parameter that needs to
>       be converted (e.g. converting the IntPtr into a Stat, above).
>   - Requires adding several new methods to 
>     Mono.Unix.Native.NativeConvert to copy structures between managed
>     and native (e.g. the NativeConvert.Copy() method used above).

The conversion methods are needed in any case, otherwise Mono.Posix is
useless for all but the trivial cases (the current design requires that
everything is remapped with Mono.Posix's view of constants, so
it ended up including tons of crap APIs... At least including the
conversion methods allows to overcome such design limitations).

> I implemented solution (1) for efficiency reasons -- why invoke extra
> P/Invoke calls when they can be avoided?
> 
> So I implemented (2) for comparison.  The result: to copy a 100000000
> byte file using `cat':
> 
> 	            Average Copy Time
> 	Solution 1:  4.8362s
> 	Solution 2:  4.8613s
> 
> Since FUSE reads file contents in 4KB chunks, there is an average
> overhead of .25us/call using (2).

Good, so there is not much overhead either: this is so much better than
exposing for public use an unmaintainable API.

> > Sorry, but there is no way to grab the mono-config.h name for this.
> 
> I'm sorry, but I don't understand this comment.

Any patch that will install a mono-config.h file for use by a library
that is not libmono itself won't be accepted (and even in that case it
won't look like the file you want to install here).

> Regardless, it sounds like you don't want MapAttribute to be a public
> API in any way, and would prefer copy+pasting code between any projects
> that want to make use of the make-map.exe mechanism.
> 
> I'm not entirely fond of extra copy+pasting if not necessary...
> 
> So a question/proposal: could we make make-map.exe/create-native-map
> follow the "Applications Guidelines" for an unstable API to copy
> create-native-map.exe itself and a .cs file for use within that
> application?
> 
> Thus, instead of Mono.Posix.dll exporting a public attribute, we have an
> easier way for people to make use of create-native-map without them
> needing to copy the existing source code (they can instead copy an
> existing binary & update as needed).

You're trying to expose a private, limited-purpouse and hackish tool
for general use. We can't endorse that, because we'd have to maintain
compatibility of the tool and of its output. Put up a web page, maybe
even use a (separate) svn module in the mono repository, but mcs/ is not
a place for dumping any tool we can think of (especially hackish tools
like make-map.exe).

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better