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

[Christoph Hellwig]

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.

> + * 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?

> +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?