Re: Re: [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP_HANDLE operation

[Horst Birthelmer <horst@birthelmer.de>]

On Fri, Jan 09, 2026 at 05:07:10PM +0000, Luis Henriques wrote:
> On Fri, Jan 09 2026, Horst Birthelmer wrote:
> 
> > On Fri, Jan 09, 2026 at 02:45:21PM +0000, Luis Henriques wrote:
> >> On Fri, Jan 09 2026, Miklos Szeredi wrote:
> >> 
> >> > On Fri, 9 Jan 2026 at 12:57, Luis Henriques <luis@igalia.com> wrote:
> >> >
> >> >> I've been trying to wrap my head around all the suggested changes, and
> >> >> experimenting with a few options.  Since there are some major things that
> >> >> need to be modified, I'd like to confirm that I got them right:
> >> >>
> >> >> 1. In the old FUSE_LOOKUP, the args->in_args[0] will continue to use the
> >> >>    struct fuse_entry_out, which won't be changed and will continue to have
> >> >>    a static size.
> >> >
> >> > Yes.
> >> >
> >> >> 2. FUSE_LOOKUP_HANDLE will add a new out_arg, which will be dynamically
> >> >>    allocated (using your suggestion: 'args->out_var_alloc').  This will be
> >> >>    a new struct fuse_entry_handle_out, similar to fuse_entry_out, but
> >> >>    replacing the struct fuse_attr by a struct fuse_statx, and adding the
> >> >>    file handle struct.
> >> >
> >> > Another idea: let's simplify the interface by removing the attributes
> >> > from the lookup reply entirely.  To get back the previous
> >> > functionality, compound requests can be used: LOOKUP_HANDLE + STATX.
> >> 
> >> OK, interesting idea.  So, in that case we would have:
> >> 
> >> struct fuse_entry_handle_out {
> >> 	uint64_t nodeid;
> >> 	uint64_t generation;
> >> 	uint64_t entry_valid;
> >> 	struct fuse_file_handle fh;
> >> }
> >> 
> >> I'll then need to have a look at the compound requests closely. (I had
> >> previously skimmed through the patches that add open+getattr but didn't
> >> gone too deep into it.)
> >> 
> >
> > I am preparing the pull request for libfuse today, so you can have a look at how it will be handled on the libfuse
> > side. 
> > That contains a patch to passthrough_hp as well so it supports compounds and you will have something to test, if you want to go that way.
> 
> Awesome, thanks for the hint, Horst.  I'll definitely have a look into it.
> 
FWIW, I have updated the PR for libfuse so that passthrough_hp now demoes the two ways we can handle compounds.
The one where we just call the requests in the compound sequencially (here we have a helper in the lib now) and
the  way where we create a special function to take care of atomic combinations of requests.
I hope that helps to understand the idea better.

> Cheer,
> -- 
> Luís

Thanks,
Horst