Some concerns about recent FUSE ops.

Hi,

I have worked with FUSE for many years now, especially network filesystems.

I've got a growing concern about the recent growth of the FUSE flags
and options.
In my opinion there are some options which should or go into
userspace, or are only to be used in niches.

For example the FUSE_NO_OPEN en FUSE_NO_OPENDIR bits. Are there any
use cases? I doubt there are.

Is FUSE_READIR_PLUS_AUTO really required? I doubt it. If you are
creating a FUSE fs, you know at INIT what the fs needs and is able to,
so the automatic thing is not required.

Is FUSE_HANDLE_KILLPRIV just bogus, and was not really thought
through? Since there is
FUSE_HANDLE_KILLPRIV_V2.

Are FUSE_NO_EXPORT_SUPPORT really necessary? Since there is FUSE_EXPORT_SUPPORT.

FUSE_OVER_IO_URING is technically a challenge, but does not offer
extra functionality. When the  FUSE service is doing io_ring to get IO
going, that is very possible, but it should use them in combination
with the normal read and write (and notify) callbacks.
In my vision you do IO_URING on the backend, not on the waiting client (==VFS).

FUSE_REQUEST_TIMEOUT is really not required. I've written FUSE fs;s
using a timeout,
and when expired/timeout, an error is sent to the VFS (ETIMEDOUT) and
it is all handled as it should.

Please think about it, I'm concerned, and worried that at this pace we
just need another set of 32 bits of options in a year or so.
And maybe I've written here something you totally do not agree with.
Ok, let's discuss.

Stef Bon
The Netherlands