On Mon, Sep 14, 2020 at 04:26:17PM +0100, Matthew Wilcox wrote: > On Mon, Sep 14, 2020 at 04:44:16PM +0200, Christoph Hellwig wrote: > > I'm still a little unsure about the API naming, as alloc_pages sort of > > implies a struct page return value, but we return a kernel virtual > > address. > > Erm ... dma_alloc_pages() returns a struct page, so is this sentence > stale? Yes. > You say that like it's a bad thing. I think the problem is more that > people don't understand what non-coherent means and think they're > supporting it when they're not. > > dma_alloc_manual_flushing()? That sounds pretty awkward.. > > > As a follow up I plan to move the implementation of the > > DMA_ATTR_NO_KERNEL_MAPPING flag over to this framework as well, given > > that is also is a fundamentally non coherent allocation. The replacement > > for that flag would then return a struct page, as it is allowed to > > actually return pages without a kernel mapping as the name suggested > > (although most of the time they will actually have a kernel mapping..) > > If the page doesn't have a kernel mapping, shouldn't it return a PFN > or a phys_addr? Most APIs we'll feed it into need a struct page. The difference is just that it can be a highmem page. And if we want to get fancy we could change the kernel mapping to PROT_NONE eventually.
