On Thu, Nov 03, 2022 at 11:35:15AM +1100, Dave Chinner wrote: > My first thought was to make this a page op, but I ended up deciding > against that because it isn't operating on the folio at all. > Perhaps I misunderstood what "page_ops" was actually intended for, > because it seems that the existing hooks are to allow the filesystem > to wrap per-folio operations with an external context, not to > perform iomap-specific per-folio operations. > > I guess if I read "pageops" as "operations to perform on each folio > in an operation", Yes, that was the idea behind it. iomap_ops is really just the iteration, and I've still not given up on the plan from willy to merge the two ops into a single next iterator eventually. So basic idea is iomap_ops - complete generic iterator, that just returns and finishes of an iomap. iomap_page_ops - callbacks for each folio (used to be page) > then validating the iomap is not stale once the > folio is locked could be considered a page op. I think we could > probably make that work for writeback, too, because we have the > folio locked when we call ->map_blocks.... .. and then separate ops for users of iomap, like the writeback code with iomap_writeback_ops.
