Re: Re: [PATCH v6 1/3] fuse: add compound command to combine multiple requests

[Miklos Szeredi]

On Mon, 2 Mar 2026 at 10:56, Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:
>
> On Fri, Feb 27, 2026 at 10:45:36AM +0100, Miklos Szeredi wrote:
> > On Thu, 26 Feb 2026 at 17:43, Horst Birthelmer <horst@xxxxxxxxxxxxxx> wrote:
> > > +
> > > +       unsigned int max_count;
> > > +       unsigned int count;
> > > +};
> > > +/*
> > > + * This is a hint to the fuse server that all requests are complete and it can
> > > + * use automatic decoding and sequential processing from libfuse.
> > > + */
> > > +#define FUSE_COMPOUND_SEPARABLE (1 << 0)
> >
> > We really need per sub-request flags, not per-compound flags.
> >
> > I.e:
> >
> > FUSE_SUB_IS_ENTRY - this sub request will return a new entry on
> > success (nodeid, filehandle)
> > FUSE_SUB_DEP_ENTRY - this sub request depends on the result of a previous lookup
> >
>
> Couldn't we just save boolean flags in the fuse_args?
> Something like 'bool is_sub_entry:1' and so on?

Sure, that's fine.

> If we have the automatic separation and call of requests in the kernel
> when the fuse server returns ENOSYS, I don't see the point in adding this
> to libfuse as well, since there will never be the case,  that kernel
> doesn't support compounds but libfuse does.
> It's either the fuse server handles the whole compound, or the kernel does.

No, I think the library is in a good position to handle compounds,
because that can reduce the complexity in the server while keeping
most of the performance benefits.

> My point is, we don't need to send that information anywhere.

We need to send that information in any case.  It needs to be part of
the matching done by the server to "recognize" a certain compound,
because the same sequence of operations could have different meaning
if the dependencies are different.

Thanks,
Miklos