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).
Description: PGP signature