iomap: convert to in-iter ->iomap_next() model

This is submitted to get some feedback on what converting to an in-iter
->iomap_next() model would look like. It revives Matthew's previous RFC [1],
which had the same goal.

The series merges ->iomap_begin()/->iomap_end() into a single ->iomap_next()
callback (patches 1-2) and shows an example of devirtualizing the callbacks on
a hot path so the indirect call through struct iomap_ops is avoided (patch 3).
This series is on top of vfs.all (commit e7a6d06e3c3e8).

A few questions:
* is this roughly the in-iter direction you had in mind?
* is removing the indirect call still worth it? My understanding is that
  indirect calls are cheap on modern eIBRS hardware and the conversion adds
  some per-filesystem boilerplate, so I'm unsure if it carries its weight. If
  not, do you think the in-iter model is still worth having on its own?

Thanks,
Joanne

[1] https://lore.kernel.org/linux-fsdevel/20200728173216.7184...

Joanne Koong (3):
  iomap: add ->iomap_next() and iomap_process() helper
  xfs: convert read and buffered write iomap ops to ->iomap_next()
  xfs: example of devirtualizing buffered write iomap callbacks

 fs/iomap/buffered-io.c |  3 +-
 fs/iomap/iter.c        | 99 ++++++++++++++++++++++++++++++++++--------
 fs/xfs/xfs_file.c      | 26 +++++++++--
 fs/xfs/xfs_iomap.c     | 29 ++++++++++---
 fs/xfs/xfs_iomap.h     |  7 +++
 include/linux/iomap.h  | 98 ++++++++++++++++++++++++++++++++++++++---
 6 files changed, 231 insertions(+), 31 deletions(-)

-- 
2.52.0