Re: [RFC][PATCH 1/3] xip: no struct pages -- get_xip_mem

["Jared Hulbert" <jaredeh@gmail.com>]

>  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.