On Thu, Jan 30, 2025 at 12:09:44PM -0500, Brian Foster wrote:
> In preparation for future changes and more generic use of
> iomap_iter_advance(), lift the high level iter continuation logic
> out of iomap_iter_advance() into the caller. Also add some comments
> and rework iomap_iter() to jump straight to ->iomap_begin() on the
> first iteration.
It took me a bit to reoncile the commit log with the changes.
What this does is:
1) factor out a iomap_iter_reset_iomap caller from iomap_iter_advance
2) pass an explicit count to iomap_iter_advance instead of derіving
it from iter->processed inside of iomap_iter_advance
3) only call iomap_iter_advance condititional on iter->iomap.length,
and thus skipping the code that is now in iomap_iter_reset_iomap
when iter->iomap.length is 0.
All this looks fine, although I wonder why we didn't do 3) before and
if there is a risk of a regression for some weird corner case.
I hate nitpicking too much, but maybe split the three steps into
separate patches so that 3) is clearly documented and can be bisected
if problems arise?
