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

["Darrick J. Wong" <djwong@kernel.org>]

On Fri, Jul 03, 2026 at 05:34:59PM -0700, Joanne Koong wrote:
> 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.

Oh right, iomap_iter::private is a private pointer that the filesystem
can sometimes set to pass per-file-operation data to ->iomap_{begin,end}
... that is tortuously extracted from the iomap_iter via the iomap
pointer.

iomap::private is a private pointer that the filesystem can set to pass
per-mapping data from ->iomap_begin to ->iomap_end.

IOWS, never mind, I'm babbling nonsense.

--D

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