Hi David,
On Thu, Jan 13, 2022 at 01:27:11PM +0000, David Howells wrote:
> Jeffle Xu <jefflexu@xxxxxxxxxxxxxxxxx> wrote:
>
> > Make the @file parameter optional, and derive inode from the @folio
> > parameter instead in order to support file system internal requests.
> >
> > @file parameter can't be removed completely, since it also works as
> > the private data of ops->init_rreq().
>
> Note that I'm working towards a model where you would ordinarily point your
> file operations and/or address-space operations directly at the netfs
> functions. This will require filesystems that use it to add a bit to their
> fs-specific inode structs directly after the struct inode member.
Sorry, I'm not sure if I understand your main idea here..
Would you mind give more hints about this? Thanks in advance!
As I said earlier, what we'd like to do is to use read_cache_page_gfp()
in EROFS directly calling netfs mapping (and it's a common practice to
make fs internal requests) to get a netfs page cache page filled with
data rather than directly use netfs_alloc_read_request() or whatever.
read_cache_page_gfp
-> netfs_readpage (without file)
-> netfs_alloc_read_request
in such condition, there is no file open in advance..
Besides, what I can see is currently
int netfs_readpage(struct file *file,
struct folio *folio,
const struct netfs_read_request_ops *ops,
void *netfs_priv)
netfs_priv is actually unused (NULL), can we pass in fs private stuffs
(such as file->private_data) with this instead? and turn
void (*init_rreq)(struct netfs_read_request *rreq, struct file *file);
into
void (*init_rreq)(struct netfs_read_request *rreq, void *netfs_priv);
in order to match
void (*cleanup)(struct netfs_read_request *rreq, void *netfs_priv);
It seems all current callers leave netfs_priv as NULL:
9p/vfs_addr.c: return netfs_readpage(file, folio, &v9fs_req_ops, NULL);
afs/file.c: return netfs_readpage(file, folio, &afs_req_ops, NULL);
ceph/addr.c: return netfs_readpage(file, folio, &ceph_netfs_read_ops, NULL);
Thanks,
Gao Xiang
>
> David
--
Linux-cachefs mailing list
Linux-cachefs@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-cachefs
