On Fri, Sep 21, 2018 at 12:13:21PM -0600, Logan Gunthorpe wrote: > On 2018-09-21 10:48 AM, Bjorn Helgaas wrote: > >> I think the use of "map" in this context is slightly confusing because the > >> general expectation is that map/unmap must be balanced. > > Yeah, Jason said the same thing, but having an empty unmap function > seems wasteful and Christoph said to just remove it. My opinion is that > it's not that big an issue one way or another -- if we have to add an > unmap later it's not really that hard. > > >> If you keep "map", maybe add a sentence or two about why there's no > >> corresponding unmap? > > Will do. > > > Another wrinkle is that "map" usually takes an A and gives you back a > > B. Now the caller has both A and B and both are still valid. > > Here we pass in an SGL and the SGL is transformed, so the caller only > > has B and A has been destroyed, i.e., the SGL can no longer be used as > > it was before, and there's no way to get A back. > > I wouldn't say that. Our map_sg function is doing the same thing > dma_map_sg is: it sets the DMA address and length in the scatter list. > So B is still A just with other fields set. If the caller wanted to map > this SG in a different way they can still do so and the new DMA > address/length would override the old values. (Normally, you'd want to > unmap before doing something like that, but seeing our unmap is an empty > operation, we wouldn't have to do that.) Ok. I was assuming s->dma_address would have been already set before the call and would be overwritten by pci_p2pmem_map_sg(). But I guess that's not the case -- sounds like s->dma_address is undefined before the call. Bjorn
