Re: [PATCH v2 01/18] iomap: add ->iomap_next() and iomap_process() helper

[Joanne Koong]

On Thu, Jul 2, 2026 at 7:00 AM Christoph Hellwig <hch@xxxxxx> wrote:
>
> On Tue, Jun 30, 2026 at 05:09:16PM -0700, Joanne Koong wrote:
> > +static int iomap_iter_legacy(struct iomap_iter *iter, const struct iomap_ops *ops)
>
> Overly long line here.  Not that it really matters too much given
> that this goes away by the end of the series.

I'll fix this.

>
> > + * Iterate over filesystem-provided space mappings for the provided file range.
> > + *
> > + * This function handles cleanup of resources acquired for iteration when the
> > + * filesystem indicates there are no more space mappings, which means that this
> > + * function must be called in a loop that continues as long it returns a
> > + * positive value.  If 0 or a negative value is returned, the caller must not
> > + * return to the loop body.  Within a loop body, there are two ways to break out
> > + * of the loop body:  leave @iter.status unchanged, or set it to a negative
> > + * errno.
> > + */
> > +int iomap_iter(struct iomap_iter *iter, const struct iomap_ops *ops)
> > +{
> > +     if (ops->iomap_next)
> > +             return iomap_iter_next(iter, ops);
> > +
> > +     return iomap_iter_legacy(iter, ops);
>
> Maybe inline the code currently in iomap_iter_next here from the
> start, as that what we're getting to by the end of the series anyway.
> And just do a:
>
>         if (!ops->iomap_next))
>                 return iomap_iter_legacy(iter, ops);
>
> at the beginning?

Sounds good, I'll make this change.

>
> > +int iomap_iter_continue(const struct iomap_iter *iter, struct iomap *iomap,
> >
>
> It seems like this is largely just factored out form the old iomap_iter().
> Can you do a prep patch before this one which factors this out?
> Preferably in a way that keeps the code in roughly the same place to
> minimize the git blame disturbance?

Sounds good, I'll extract this shared logic out into a preparatory patch.

Thanks,
Joanne