On Mon, Jul 21, 2025 at 08:33:02PM -0600, Keith Busch wrote: > On Mon, Jul 21, 2025 at 09:42:23AM +0200, Christoph Hellwig wrote: > > On Sun, Jul 20, 2025 at 11:40:34AM -0700, Keith Busch wrote: > > > From: Keith Busch <kbusch@xxxxxxxxxx> > > > > > > The req_iterator just happens to have a similar fields to what the dma > > > iterator needs, but we're not necessarily iterating a bio_vec here. Have > > > the dma iterator define its private fields directly. It also helps to > > > remove eyesores like "iter->iter.iter". > > > > Going back to this after looking at the later patches. The level > > for which this iter exists is only called blk_map_* as there is > > nothing dma specific about, just mapping to physical addresses. > > > > So maybe call it blk_map_iter instead? > > But the structure yields "dma_addr_t" type values to the consumer. > Whether those are physical addresses or remapped io virtual addresses, > they're still used for direct memory access, so I think the name as-is > is a pretty good fit. There's two layers: The lower layer implemented by blk_map_iter_next just yields a phys_vec. The upper layer built on top does the dma mapping in case of the new blk_rq_dma_map_iter_start / blk_rq_dma_map_iter_next API. But in case of the old __blk_rq_map_sg API it doesn't even directly do the DMA mapping yet. And some drivers at least historically used the blk_map_sg without then doing a DMA mapping, either for MMIO or platform specific things using physical address. My hope was to eventually migrate them to use blk_map_iter_next.
