Re: [LSF/MM/BPF TOPIC] Where is fuse going? API cleanup, restructuring and more

[Luis Henriques <luis@igalia.com>]

On Mon, Feb 02 2026, Amir Goldstein wrote:

> [Fixed lsf-pc address typo]
>
> On Mon, Feb 2, 2026 at 2:51 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>>
>> I propose a session where various topics of interest could be
>> discussed including but not limited to the below list
>>
>> New features being proposed at various stages of readiness:
>>
>>  - fuse4fs: exporting the iomap interface to userspace
>>
>>  - famfs: export distributed memory
>>
>>  - zero copy for fuse-io-uring
>>
>>  - large folios
>>
>>  - file handles on the userspace API
>>
>>  - compound requests
>>
>>  - BPF scripts
>>
>> How do these fit into the existing codebase?
>>
>> Cleaner separation of layers:
>>
>>  - transport layer: /dev/fuse, io-uring, viriofs
>>
>>  - filesystem layer: local fs, distributed fs
>>
>> Introduce new version of cleaned up API?
>>
>>  - remove async INIT
>>
>>  - no fixed ROOT_ID
>>
>>  - consolidate caching rules
>>
>>  - who's responsible for updating which metadata?
>>
>>  - remove legacy and problematic flags
>>
>>  - get rid of splice on /dev/fuse for new API version?
>>
>> Unresolved issues:
>>
>>  - locked / writeback folios vs. reclaim / page migration
>>
>>  - strictlimiting vs. large folios
>
> All important topics which I am sure will be discussed on a FUSE BoF.

I wonder if the topic I proposed separately (on restarting FUSE servers)
should also be merged into this list.  It's already a very comprehensive
list, so I'm not sure it's worth having a separate topic if most of it
will (likely) be touched here already.

What do you think?

Cheers,
-- 
Luís

> I think that at least one question of interest to the wider fs audience is
>
> Can any of the above improvements be used to help phase out some
> of the old under maintained fs and reduce the burden on vfs maintainers?
>
> Thanks,
> Amir.