[ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/28/16, 10:29 AM, Mark Geisert wrote:


>>I am going to really try to get that Win 7 supporting build out by the
>>end
>> of Thursday (Pacific time).
>
>That's the timezone I'm in.  I'll see what's going on later tonight :) .

Ok, great. Then we should be able to do this today.

>My mistake.  I thought your FUSE implementation had to be compiled for
>Cygwin, 
>in order to make use of the cygfuse glue logic.  But instead you have a
>native 
>Windows FUSE implementation?  Won't you have ABI (not API) problems
>connecting 
>those two pieces, depending on how the FUSE guts are implemented?
>Apologies if 
>you've sorted that all out; don't want to hold you up talking about
>solved aspects.

Yes. I have a FUSE implementation that works for native and Cygwin
programs. The ABI was indeed a bit of an issue, hence my use of fsp_fuse_*
symbols vs fuse_* symbols.

Quick example: instead of offering a fuse_loop symbol, WinFsp offers an
fsp_fuse_loop symbol. Then fuse_new is coded as (for native):

    static inline int fuse_loop(struct fuse *f)
    {
        return fsp_fuse_loop(fsp_fuse_env(), f);
    }

Similar code is used in the cygfuse DLL (in fact the same fuse_loop
definition is used on native and Cygwin through macro (ab)use).

The fsp_fuse_env() captures the “environment” which includes things like
the local MSVCRT/Cygwin malloc, etc. I also make sure not to use long
anywhere (since its size is different on Win64 vs Cygwin64).

I have some more information on this scheme here:

http://www.secfs.net/winfsp/blog/files/sshfs-port-case-study-step-2.html

>I agree with how you want to adjust license and transfer ownership.  I
>don't
>have a presence on GitHub but I should be able to grab cygfuse anyway.

Excellent. I will change the project to BSD and will explicitly say that I
am assigning ownership to you in the README/LICENSE files.

Bill