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

[Joanne Koong <joannelkoong@gmail.com>]

On Fri, Jul 3, 2026 at 9:11 AM Darrick J. Wong <djwong@kernel.org> wrote:
>
> 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'm not sure I understand. Doesn't struct iomap_iter already have a
private field that holds caller-supplied per-operation context?
afaics, the users of iomap->private (gfs2, ntfs3, fuse-dax) do use it
for per-mapping data and release it in the same iteration.

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

That's a good point. Do you think it'd be better to include those
changes as part of this series or do that as a separate follow-up
series that targets the same merge window timeline as this one?

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

Agreed.

Thanks,
Joanne