Hi, Herbert:
> > WinFsp provides three (3) different modes of integration:
[snip]
> 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:
https://github.com/terencehonles/fusepy/blob/master/fuse.py#L66
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")))
Bill
