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

[Horst Birthelmer]

On Mon, Mar 02, 2026 at 12:03:35PM +0100, Miklos Szeredi wrote:
> 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.

OK, if I have to send flags, that are only present if the fuse request
is inside a compound then I would suggest that we preface the fuse request
with a small compound header, where we store that information.

I would not want to change the fuse request, especially not define the same
flags for every type of fuse requests.

Would that be acceptable?

> 
> Thanks,
> Miklos
> 

Thanks,
Horst