This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FUSE for Cygwin


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]