> On Thu, May 29, 2025 at 6:45 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
...
> > So I /think/ we could ask the fuse server at inode instantiation time
> > (which, if I'm reading the code correctly, is when iget5_locked gives
> > fuse an INEW inode and calls fuse_init_inode) provided it's ok to upcall
> > to userspace at that time. Alternately I guess we could extend struct
> > fuse_attr with another FUSE_ATTR_ flag, I think?
> >
>
> The latter. Either extend fuse_attr or struct fuse_entry_out,
> which is in the responses of FUSE_LOOKUP,
> FUSE_READDIRPLUS, FUSE_CREATE, FUSE_TMPFILE.
> which instantiate fuse inodes.
>
Update:
I went to look at this extension for my inode ops passthrough patches.
What I saw is that while struct fuse_attr and struct fuse_entry_out
are designed to be extended and have been extended in the past:
* 7.9:
* - add blksize field to fuse_attr
Later on, struct fuse_direntplus was introduced
* 7.21
* - add FUSE_READDIRPLUS
With struct struct fuse_entry_out/fuse_attr embedded in the middle
and I don't see any code in the kernel/lib that is prepared to handle
a change in the FUSE_NAME_OFFSET_DIRENTPLUS constant
(maybe it's there and I am missing it)
So for my own use, which only requires passing a single int backing_id
I was tempted to try and overload attr_valid{,_nsec} which are
not relevant for passthrough getattr case,
something like {attr_valid = backing_id, attr_valid_nsec = UTIME_OMIT}.
In the meanwhile, as an example I used a hole in struct fuse_attr_out
to implement backing file setup in reply to GETATTR in the wip branch [1].
Bernd,
I wonder if I am missing something w.r.t the intended extensibility of
struct fuse_entry_out/fuse_attr and current readdirplus code?
Thanks,
Amir.
[1] https://github.com/amir73il/linux/commits/fuse-backing-inode-wip/
