Re: [PATCH v2 18/18] Documentation: iomap: update docs to reflect iomap_next model

[Christoph Hellwig]

On Fri, Jul 03, 2026 at 09:11:47AM -0700, Darrick J. Wong wrote:
> > That also reminds me that now that we actually still keep the low-level
> > begin/end ops we need to switch them to a calling convention that
> > passes the iter instead of the ugly container_of.  This is something
> > I wanted deferred until we get the iter conversion, but it turns out
> > that now leaves them untouched..
> 
> Oh, you mean changing the signature to:
> 
> typedef int (iomap_begin_fn)(struct iomap_iter *iter...);
> 
> instead of passing parts of the iter as separate arguments?
> Yeah, that would be nice.

Well, at least passing the iter in some form.  Either just the iter
in mutable form, or a const iter plus non-const iomap and srcmap
as suggested by Gao and currently implemented for the next/iter
callback.

> int fubar_iomap_next(const struct iomap_iter *iter)
> {
> 	struct iomap *i = (struct iomap *)&iter->iomap;
> 	struct iomap *s = (struct iomap *)&iter->srcmap;
> 	...
> }
> 
> to simplify the call sites.  The gross part of this is (1) having a
> const iomap_iter pointer to prevent filesystems from screwing around
> with the iter, and therefore (2) the need for explicit casting to remove
> the constness from the two iomappings.

Yeah, if we pass only the iter it'd better be non-const.