This is the mail archive of the
mailing list for the Cygwin project.
Re: FUSE for Cygwin
- From: Bill Zissimopoulos <billziss at navimatics dot com>
- To: "cygwin at cygwin dot com" <cygwin at cygwin dot com>
- Date: Fri, 17 Jun 2016 20:29:32 +0000
- Subject: Re: FUSE for Cygwin
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp dot mailfrom=billziss at navimatics dot com;
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
> > WinFsp provides three (3) different modes of integration:
> i'm planning to make a suggestion of mode (4). It will be in addition or
> instead of (3) and will avoid those issues we touched.
I think (based on your earlier ask re: bindings to Python, Perl, etc.) I
may see what you mean with mode (4). Perhaps a libfuse Cygwin DLL that
presents an API *exactly* like the one from FUSE?
Currently WinFsp goes through a number of hoops to support the Win32 and
Cygwin environments with a single DLL. As a result a call to fuse_new is
really a call to fsp_fuse_new through a static inline function.
static inline struct fuse *fuse_new(...)
return fsp_fuse_new(fsp_fuse_env(), ...);
Fsp_fuse_env âcapturesâ the environment (e.g. the local malloc/free) so
that the WinFsp DLL can remain environment independent. But this scheme
will not (and cannot) work for e.g. Python bindings that need to dlopen
the âfuseâ library. Here is FUSEPY, as example:
If that is indeed your plan I would support it.
Creating a libfuse Cygwin DLL like that should be easy. Perhaps I can help
by making the âstatic inlineâ part a macro such as FSP_FUSE_STATIC_INLINE,
which one could redefine to __attribute__ ((visibility("default")))