This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: cygfuse
- From: Bill Zissimopoulos <billziss at navimatics dot com>
- To: "cygwin-apps at cygwin dot com" <cygwin-apps at cygwin dot com>
- Date: Wed, 21 Sep 2016 06:01:31 +0000
- Subject: Re: cygfuse
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=billziss at navimatics dot com;
- References: <D3BF7FAD.A9C3%billziss@navimatics.com> <579A4102.9040406@maxrnd.com> <D3BFA5AD.AA0D%billziss@navimatics.com> <20160728200435.GG26311@calimero.vinschen.de> <D3BFC46B.AA41%billziss@navimatics.com> <20160729085141.GK26311@calimero.vinschen.de> <D406F19F.B3EF%billziss@navimatics.com> <Pine.BSF.4.63.1609202225470.89347@m0.truegem.net>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 9/20/16, 10:33 PM, Mark Geisert wrote:
>On Tue, 20 Sep 2016, Bill Zissimopoulos wrote:
>> Mark, has there been any additional progress on this?
>
>No activity. I was not expecting Dokany to be fully integrated before
>ITPing cygfuse, but I had hoped to hear at least that the layout of FUSE
>include files works for them (or doesn't) and that the strategy of
>dynamic
>loading Dokany's DLL is workable for them too.
I am no Dokany expert, but I would think that the dlopen strategy will
work for them as well. They export FUSE symbols such as fuse_new, etc.
https://github.com/dokan-dev/dokany/blob/master/dokan_fuse/src/dokanfuse.de
f
>> Looking at the updated cygfuse I believe one change would be to rename
>> cygfuse.pc back to fuse.pc so that build configuration scripts can find
>> it. I have created a github issue for this.
>
>I've now made those changes and updated the GitHub issue. Should the URL
>named in fuse.pc.in now point at the GitHub cygfuse project?
Yes, I think only the cygfuse project should be referenced.
>> Other than that I would think that the package would be ready for
>> submission. Any changes to support additional projects like Dokany, etc.
>> could easily happen in the future when those projects are ready.
>
>Agreed. It would be neet though to find out sooner rather than later
>whether some other FUSE implementation can coexist with WinFSP. I don't
>have the bandwidth to check Dokany or any others myself despite interest.
The only gotcha that I see is with the header files. I recommend that you
eventually create a new cygfuse-winfsp.c file and move all WinFsp specific
code in there. Some of the code from the header files will have to be
moved into this new file (cygfuse-winfsp.c). Then the header files could
have all WinFsp specific references removed. Notice that under normal
circumstances (e.g. when used to compile SSHFS) the FSP_FUSE_* macros get
defined as:
#define FSP_FUSE_API __declspec(dllimport)
#define FSP_FUSE_API_NAME(n) (n)
#define FSP_FUSE_API_CALL(n) (n)
#define FSP_FUSE_SYM(proto, ...) proto;
I would hope though that the ITP happens before this refactoring. I have
SSHFS and (possibly) FUSEPY ports that I would like to submit :)
Bill