Re: Re: [PATCH v2 12/21] fuse: add struct fuse_entry2_out and helpers for extended entry replies
Horst Birthelmer <[email protected]> Sat, 16 May 2026 21:29:37 +0200
| Newsgroups | org.kernel.vger.linux-unionfs,dev.linux.lists.fuse-devel |
|---|---|
| Message-ID | <[email protected]> |
On Sat, May 16, 2026 at 07:25:05PM +0200, Amir Goldstein wrote: > On Sat, May 16, 2026 at 2:52 AM Joanne Koong <[email protected]> wrote: > > > > Add struct fuse_entry2_out, which is a new extended entry reply struct > > that carries a backing_id and statx attributes. This will be necessary > > for setting fuse passthrough on inodes. > > > > Add helpers that subsequent commits will use to process fuse_entry2_out > > for passthrough support for lookup, revalidate, and create. > > fuse_statx_to_attr() is also moved to earlier in the file to avoid > > forward declaring. > > > > I think you had a discussion with Miklos about whether > it makes sense to do a compound response for LOOKUP+STATX. > I don't remember the conclusion, but if this can save us all the > if (use_entry2) { } else {} all over the code, then I think it is worth it. > > Can you give me the bottom line from your discussion or was there > no conclusion reached? > > If we do that, where do we return backing_id? > Could make use of the reserved[] fields in fuse_statx_out. > > I happen to have a test patch at the tip of my fuse-backing-inode-wip > branch: > 6e296625eafd6 fuse: support setting backing inode passthrough on getattr > > It's not using the statx response, and it was just done for testing, > but in theory, > if a server wants to change an inode from non-passthrough to > yes-passthrough mid lifetime > doing this on attribute cache expiry may make more sense than on entry > timeout expiry, because backing_id is an attribute of the inode not the dentry. Hi Amir, I see there is a lot of talk about using the compounds in a couple of different contexts. I really have to apologize for not having the latest patch ready by now, but I'm a bit unsure how to do it. I'm not entirely sure if compounds will only be a thing for fusex or if it will ever be accepted for the classic FUSE. I actually have a patch that I have not tested well enough, since I have to maintain our own version and then have to do the fusex one and probably the new verison for the classic FUSE version. So, sorry about that, but I'm not having enough clarity on what to focus on. > > Not sure if this is making any sense. > > Thanks, > Amir. > Horst