Re: [post LSFMM summary] where is fuse going?

[Luis Henriques <luis@igalia.com>]

On Mon, May 11 2026, Horst Birthelmer wrote:

> On Mon, May 11, 2026 at 05:43:46PM +0100, Luis Henriques wrote:
>> Hi Miklos,
>> 
>> On Mon, May 11 2026, Miklos Szeredi wrote:
>> 
>> > Please let know what I missed.
>> 
>> Thanks for the summary.  It looks pretty comprehensive to me, the only
>> things I don't see listed are the FUSE discord and the monthly/biweekly
>> call.  But that's probably out of the scope of this email.
>> 
>> Also...
>> 
>> [snip]
>> 
>> > COMPOUND REQS: let's add this to fusex.  uAPI is simple, kAPI needs refining.
>> >
>> > FILE HANDLES: same: let's add to fusex.
>> 
>> I'd like to clarify this: do you see fusex as some sort of staging area
>> for features development that would (or could) eventually be merged back
>> into the "traditional" FUSE?
>> 
>> I'm asking because I got under the impression that file handles in
>> particular was something that would be desired to have in "traditional"
>> FUSE (and that's where I would rather have them TBH).  This would, for
>> example, help unbreak nfs exports.
>> 
>
> I'm not that convinced that this is as easily doable as it looks at first glance.
> Imagine you have a feature done in fusex.
> The interface to vfs is the same and the interface to user space is the same
> (to some degree, since there are those new opcodes)
> but the inner workings are completely different.
>
> I think the porting to traditinal fuse will pretty much be a rewrite, unless the
> task was trivial in the first place.

Right, I got the same feeling looking into the code.  But since the patch
description explicitly mentions this possibility of merging features into
the old code base, I figured I'd ask just to be sure.

Miklos, do you have a timeline for when fusex will be merged into
mainline?

Cheers,
-- 
Luís