On Fri, Mar 07, 2008 at 11:37:32PM -0800, Linus Torvalds wrote: > > > On Fri, 7 Mar 2008, Jared Hulbert wrote: > > > > [RFC][PATCH 1/3] xip: no struct pages -- get_xip_mem > > > > Convert XIP to support non-struct page backed memory. > > The get_xip_page API is changed from a page based to an address/pfn based one. > > 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. > > 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. It's not quite the same. get_xip_mem is used not just for page faults, but also for read(2) and write(2) -- this really is the whole reason why it wants a pfn and a kaddr: for the fault path, you need to install the pfn, for read or write, the kernel wants a handle on the memory. I think I'd rather not use vm_fault at the moment, and definitely not unify it with fault (I'm still trying to unify nopage, nopfn, and page_mkwrite with fault; and all of those really are special cases of a fault). Anyway, I'm just reposting the patchset, I'd love to get the ball rolling again... -- 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