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

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..)