Re: [PATCH v2 02/18] xfs: convert iomap ops to ->iomap_next()

From: Christoph Hellwig

Date: Mon Jul 20 2026 - 04:24:15 EST


On Fri, Jul 17, 2026 at 02:48:03PM -0700, Joanne Koong wrote:
> > > > > > > + return iomap_process(iter, iomap, srcmap, xfs_direct_write_iomap_begin,
> > > > > > > + NULL);
> > > > > >
> > > > > > But then "iomap_iter" sets up a new problem: should iomap_process have a
> > > > > > new name that goes along with that? iomap_iter is already taken for the
>
> I'm starting not to like "iomap_process()" either, it seems too vague...

It is.

> I think it'd be better renamed to "iomap_iter_next()". The callsites
> would then just look something like:
>
> static int
> xfs_read_iomap_next(
> const struct iomap_iter *iter,
> struct iomap *iomap,
> struct iomap *srcmap)
> {
> return iomap_iter_next(iter, iomap, srcmap, xfs_read_iomap_begin, NULL);
> }
>
> static int
> xfs_seek_iomap_next(
> const struct iomap_iter *iter,
> struct iomap *iomap,
> struct iomap *srcmap)
> {
> return iomap_iter_next(iter, iomap, srcmap, xfs_seek_iomap_begin, NULL);
> }

Looks fine. And this might also be on of the rare case where a littl macro
magic to generate this might fine. I.e. turn this into:

static DEFINE_IOMAP_ITER_NEXT(xfs_read_iomap_next, xfs_seek_iomap_begin);
static DEFINE_IOMAP_ITER_NEXT(xfs_seek_iomap_next, xfs_read_iomap_begin);

and

static DEFINE_IOMAP_ITER_NEXT_END(xfs_buffered_write_iomap_next,
xfs_buffered_write_iomap_begin, xfs_buffered_write_iomap_end);

(could be shorted with string concatenations, but those are really annoying..)