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

[Darrick J. Wong]

On Fri, Jul 03, 2026 at 02:43:31PM +0200, Christoph Hellwig wrote:
> On Thu, Jul 02, 2026 at 07:00:20PM -0700, Darrick J. Wong wrote:
> > The ->begin method can still set iomap::private and the ->end method can
> > dispose of it, right?  Oh, wait, no, that doesn't work because you're
> > talking about ->begin/->end passing something to the next ->begin.
> 
> Should we move ->private from struct iomap to struct iomap_iter?
> That'll deal with the constness and the fact that private data
> really is a per-operation thing.

I dunno -- towards the end of the fuse-iomap development work I actually
had started using iomap.private to store per-mapping private data.  But
that work is dead now, so that's not a strong argument.

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

> > Hm.  I was thinking that the signature for iomap_process could be
> > cleaner if you didn't have to pass iomap/srcmap explicitly.
> > iomap_process could do the (dangerous) casting from the (const struct
> > iomap_iter *) to the (struct iomap *) pointers before calling ->begin
> > and ->end.
> 
> I don't quite understand those part.

Let me try again.  Instead of passing three arguments:

int fubar_iomap_next(const struct iomap_iter *iter,
	struct iomap *i, struct iomap *s)
{
	...
}

pass one instead:

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.

--D