> Is there any way we could just re-use the same calling conventions as we
> already use for "vma->fault()"?
>
>
> > + int (*get_xip_mem)(struct address_space *, pgoff_t, int, void **,
> > + unsigned long *);
>
> This really looks very close to
>
> int (*fault)(struct vm_area_struct *vma, struct vm_fault *vmf);
>
> and "struct vm_fault" returns either a kernel virtual address or a "struct
> page *"
>
> So would it be possible to just use the same calling convention, except
> passing a "struct address_space" instead of a "struct vm_area_struct"?
>
> I realize that "struct vm_fault" doesn't have a pfn in it (if they don't
> do a "struct page", they are expected to fill in the PTE directly instead
> and return VM_FAULT_NOPAGE), but I wonder if it should.
I think that makes a lot of sense. The get_xip_mem() also takes in
vmf->pgoff as an input, yeah that would be nice. I'll do that Monday.
> The whole git_xip_page() issue really looks very similar to "fault in a
> page from an address space". It feels kind of wrong to have filesystems
> implement two functions for what seems to be the exact same issue.
get_xip_mem() does look similar to fault() but if you at it's place in
call stack it's more like
int (*readpage)(struct file *, struct page *);
In AXFS depending on whether a page is XIP or not
axfs_fault() > filemap_fault() > axfs_readpage()
Or for an XIP page it's
axfs_fault() > xip_file_fault() > get_xip_mem()
So I it doesn't feel like overlap to me. I think the overlap is
actually upstream in filemap_fault() vs xip_file_fault(). But I'm not
smart enough to figure it out yet.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
