tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: More compatibility for refuse



Taylor R Campbell <campbell+netbsd-tech-userlevel%mumble.net@localhost> writes:

>> Date: Wed, 10 Apr 2019 19:50:02 +0000
>> From: coypu%sdf.org@localhost

>> I'm just going to commit code without code review if all the responses
>> are going to be "please don't work on X, work on Y instead".
>> I am interested in librefuse because that's what gets used.
>
> May I suggest the following rephrasing?
>
> `Cool, thanks, how do I make fuse-ntfs-3g and fuse-ext2 use it?
> What's the costs/benefits to using libfuse via perfused, versus
> librefuse?  Is there a reason to prefer one over the other going
> forward?'

That's a fair question and request.  But, in this case, separately from
valid concerns about discourse, I think the situation is:

librefuse via puffs is and has been the standard approach on NetBSD for
high-level API access.  Using the high-level API is the standard
approach for filesystems (I am aware of only gluster needing the
low-level API).

As I understand things, the FUSE high-level API defined by the FUSE
project is not as stable as one would like, and backwards compat is not
as good as one would like.  Therefore filesystems more or less have to
stay current with the FUSE API (but apparently some don't quite).

Therefore:

  perfuse has to stay and be supported (but there is no actual
  discussion otherwise, just a single question)

  librefuse should support the current high-level API.

  There is no real need for compat to older APIs, in that filesystems
  that would benefit from that compat won't run without patching on
  other operating systems.

  It would perhaps be nice to allow building against older APIs,
  basically emulating what upstream FUSE probably should have done, and
  I gather opinions differ about the merits of this.


So:

  Obviously maya@ thinks that having compat for old APIs in librefuse is
  good.

  I am unclear on whether the cognitive load is worth the gain, as in
  pkgsrc any filesystem needs to be updated to the current FUSE
  high-level API anyway.  Given that it seems like not a lot of lines of
  .h/.c, I don't see much harm.

  I don't know if manu@ objects to API compat, or merely objects to the
  notion the perfuse isn't necessary.

  I don't know what anybody else thinks about API compat (in our
  librefuse; opinions about the wisdom of upstream are sort of
  interesting but not really on point).

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index