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

[Horst Birthelmer]

On Thu, Feb 12, 2026 at 11:23:56AM +0100, Miklos Szeredi wrote:
> On Thu, 12 Feb 2026 at 10:53, Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:
> >
> >
> > Exactly. And the FUSE_COMPOUND_SEPARABLE was actually there to tell the fuse server,
> > that we know that this is not done in this case, so the requests can be processed
> > 'separately'.
> > If that is missing the fuse server has to look at the combination and decide wether it
> > will execute it as a 'compound' or return an error.
> 
> I'd rather add some sub-op header flag that how to fill the missing
> input.  E.g. use the nodeid from the previous op's result.
> 
> If there's no flag, then the op is "separable".
> 

This makes the handling on the fuse server side unnecessarily harder.
With the current way I can check the flag in the compound header and let libfuse handle the
compound by calling the request handlers separately, and not worry about a thing.

If the flag is not there, the fuse server itself 
(passthrough_hp from the PR already demonstrates this) has to handle the whole compound
as a whole. I'm confident that this way we can handle pretty much every semantically
overloaded combination.

The other way would make the handling in libfuse or in the lowest level of the fuse server
(for fuse servers that don't use libfuse) almost impossible without parsing all the requests
and all the flags to know that we would have been able to get away with very little work.

I had thought of a hierarchical parsing of the compound.
The fuse server can decide
1. does it handle compounds at all
2. does it support this particular compound (based on the opcodes and the compound flags
and the particular capabilities of the fuse server)
3. if the particular compound can not be handled can libfuse handle it for us?

This way we can have real atomic operations in fuse server, where it supports it.

> > > > FUSE_COMPOUND_ATOMIC was an idea to hint to the fuse server that the kernel treats
> > > > the compound as one atomic request. This can maybe save us some checks for some
> > > > compounds.
> > >
> > > Do you have an example?
> >
> > Yes, I have used it for my (not yet ready for scrutiny) implementation of atomic open.
> > If you know that LOOKUP got a valid result and the operation was atomic on fuse server side,
> > you don't have to check for MKNODs result.
> 
> As noted in my reply to Bernd the LOOKUP+MKNOD may not be the best way
> to use compounds. May be better off sticking with an actual atomic op
> for this.
> 

I don't understand yet, why.
I think we could actually implement a real atomic open if we craft a compound for it and
the fuse server supports it. If not, we can go back to the way it is handled now.

What am I missing here?

> Thanks,
> Miklos

Thanks,
Horst