From: "Darrick J. Wong" <djwong@kernel.org>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: brauner@kernel.org, hch@lst.de, willy@infradead.org,
hsiangkao@linux.alibaba.com, linux-fsdevel@vger.kernel.org,
linux-xfs@vger.kernel.org, Carlos Maiolino <cem@kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 02/18] xfs: convert iomap ops to ->iomap_next()
Date: Thu, 2 Jul 2026 09:43:39 -0700 [thread overview]
Message-ID: <20260702164339.GI9392@frogsfrogsfrogs> (raw)
In-Reply-To: <20260701000949.1666714-3-joannelkoong@gmail.com>
On Tue, Jun 30, 2026 at 05:09:17PM -0700, Joanne Koong wrote:
> Convert xfs iomap_ops to the new ->iomap_next() callback. This uses the
> iomap_process() helper, which finishes the previous mapping if needed
> and produces the next one. No functional changes are intended.
>
> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> ---
> fs/xfs/xfs_file.c | 4 +-
> fs/xfs/xfs_iomap.c | 96 +++++++++++++++++++++++++++++++++++++++++-----
> 2 files changed, 88 insertions(+), 12 deletions(-)
>
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index 845a97c9b063..7f8bef1a9954 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -857,9 +857,9 @@ xfs_file_dio_write_atomic(
> NULL, 0);
>
> /*
> - * The retry mechanism is based on the ->iomap_begin method returning
> + * The retry mechanism is based on the ->iomap_next method returning
> * -ENOPROTOOPT, which would be when the REQ_ATOMIC-based write is not
> - * possible. The REQ_ATOMIC-based method typically not be possible if
> + * possible. The REQ_ATOMIC-based method is typically not possible if
> * the write spans multiple extents or the disk blocks are misaligned.
> */
> if (ret == -ENOPROTOOPT && dops == &xfs_direct_write_iomap_ops) {
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index 225c3de88d03..4fa1a5c985db 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -1037,8 +1037,18 @@ xfs_direct_write_iomap_begin(
> return error;
> }
>
> +static int
> +xfs_direct_write_iomap_next(
> + const struct iomap_iter *iter,
> + struct iomap *iomap,
> + struct iomap *srcmap)
<unvarnished brainstream ahead>
Now that I see the callsites, I think the "next" name could use some
bikeshedding <cough>. The purpose of this function is either
(a) to look up the first mapping to start iterating;
(b) to release whatever resources were attached during the current
iteration and look up the next mapping to continue iterating; or
(c) to decide that it's time to stop iterating.
From that it seems obvious to me that xfs_direct_write_iomap_next yields
iomaps for iteration. In Python those are called generator functions;
in Rust they're called objects that implement the Iterator trait (or
iterators for short).
How about s/iomap_next/iomap_iter/ ?
Then this function would be called xfs_direct_write_iomap_iter, which
IMO is a closer description of what the function does, which is to say
iterates iomaps for direct writes.
(Yes, my brain might be polluted with thinking that "iomap next" refers
to a major shift, in the sense of "linux next". :P)
> +{
> + return iomap_process(iter, iomap, srcmap, xfs_direct_write_iomap_begin,
> + NULL);
But then "iomap_iter" sets up a new problem: should iomap_process have a
new name that goes along with that? iomap_iter is already taken for the
legacy path. If we were emulating python I'd suggest iomap_iter_yield
but this is C so we get to reinvent everything from scratch so who
knows.
--D
> +}
> +
> const struct iomap_ops xfs_direct_write_iomap_ops = {
> - .iomap_begin = xfs_direct_write_iomap_begin,
> + .iomap_next = xfs_direct_write_iomap_next,
> };
>
> #ifdef CONFIG_XFS_RT
> @@ -1089,8 +1099,18 @@ xfs_zoned_direct_write_iomap_begin(
> return 0;
> }
>
> +static int
> +xfs_zoned_direct_write_iomap_next(
> + const struct iomap_iter *iter,
> + struct iomap *iomap,
> + struct iomap *srcmap)
> +{
> + return iomap_process(iter, iomap, srcmap,
> + xfs_zoned_direct_write_iomap_begin, NULL);
> +}
> +
> const struct iomap_ops xfs_zoned_direct_write_iomap_ops = {
> - .iomap_begin = xfs_zoned_direct_write_iomap_begin,
> + .iomap_next = xfs_zoned_direct_write_iomap_next,
> };
> #endif /* CONFIG_XFS_RT */
>
> @@ -1274,8 +1294,18 @@ xfs_atomic_write_cow_iomap_begin(
> return error;
> }
>
> +static int
> +xfs_atomic_write_cow_iomap_next(
> + const struct iomap_iter *iter,
> + struct iomap *iomap,
> + struct iomap *srcmap)
> +{
> + return iomap_process(iter, iomap, srcmap,
> + xfs_atomic_write_cow_iomap_begin, NULL);
> +}
> +
> const struct iomap_ops xfs_atomic_write_cow_iomap_ops = {
> - .iomap_begin = xfs_atomic_write_cow_iomap_begin,
> + .iomap_next = xfs_atomic_write_cow_iomap_next,
> };
>
> static int
> @@ -1298,9 +1328,18 @@ xfs_dax_write_iomap_end(
> return xfs_reflink_end_cow(ip, pos, written);
> }
>
> +static int
> +xfs_dax_write_iomap_next(
> + const struct iomap_iter *iter,
> + struct iomap *iomap,
> + struct iomap *srcmap)
> +{
> + return iomap_process(iter, iomap, srcmap, xfs_direct_write_iomap_begin,
> + xfs_dax_write_iomap_end);
> +}
> +
> const struct iomap_ops xfs_dax_write_iomap_ops = {
> - .iomap_begin = xfs_direct_write_iomap_begin,
> - .iomap_end = xfs_dax_write_iomap_end,
> + .iomap_next = xfs_dax_write_iomap_next,
> };
>
> /*
> @@ -2168,9 +2207,19 @@ xfs_buffered_write_iomap_end(
> return 0;
> }
>
> +static int
> +xfs_buffered_write_iomap_next(
> + const struct iomap_iter *iter,
> + struct iomap *iomap,
> + struct iomap *srcmap)
> +{
> + return iomap_process(iter, iomap, srcmap,
> + xfs_buffered_write_iomap_begin,
> + xfs_buffered_write_iomap_end);
> +}
> +
> const struct iomap_ops xfs_buffered_write_iomap_ops = {
> - .iomap_begin = xfs_buffered_write_iomap_begin,
> - .iomap_end = xfs_buffered_write_iomap_end,
> + .iomap_next = xfs_buffered_write_iomap_next,
> };
>
> static int
> @@ -2214,8 +2263,17 @@ xfs_read_iomap_begin(
> shared ? IOMAP_F_SHARED : 0, seq);
> }
>
> +static int
> +xfs_read_iomap_next(
> + const struct iomap_iter *iter,
> + struct iomap *iomap,
> + struct iomap *srcmap)
> +{
> + return iomap_process(iter, iomap, srcmap, xfs_read_iomap_begin, NULL);
> +}
> +
> const struct iomap_ops xfs_read_iomap_ops = {
> - .iomap_begin = xfs_read_iomap_begin,
> + .iomap_next = xfs_read_iomap_next,
> };
>
> static int
> @@ -2302,8 +2360,17 @@ xfs_seek_iomap_begin(
> return error;
> }
>
> +static int
> +xfs_seek_iomap_next(
> + const struct iomap_iter *iter,
> + struct iomap *iomap,
> + struct iomap *srcmap)
> +{
> + return iomap_process(iter, iomap, srcmap, xfs_seek_iomap_begin, NULL);
> +}
> +
> const struct iomap_ops xfs_seek_iomap_ops = {
> - .iomap_begin = xfs_seek_iomap_begin,
> + .iomap_next = xfs_seek_iomap_next,
> };
>
> static int
> @@ -2349,8 +2416,17 @@ xfs_xattr_iomap_begin(
> return xfs_bmbt_to_iomap(ip, iomap, &imap, flags, IOMAP_F_XATTR, seq);
> }
>
> +static int
> +xfs_xattr_iomap_next(
> + const struct iomap_iter *iter,
> + struct iomap *iomap,
> + struct iomap *srcmap)
> +{
> + return iomap_process(iter, iomap, srcmap, xfs_xattr_iomap_begin, NULL);
> +}
> +
> const struct iomap_ops xfs_xattr_iomap_ops = {
> - .iomap_begin = xfs_xattr_iomap_begin,
> + .iomap_next = xfs_xattr_iomap_next,
> };
>
> int
> --
> 2.52.0
>
>
next prev parent reply other threads:[~2026-07-02 16:43 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 0:09 [PATCH v2 00/18] iomap: convert to in-iter iomap_next() model Joanne Koong
2026-07-01 0:09 ` [PATCH v2 01/18] iomap: add ->iomap_next() and iomap_process() helper Joanne Koong
2026-07-02 14:00 ` Christoph Hellwig
2026-07-02 23:01 ` Joanne Koong
2026-07-02 16:23 ` Darrick J. Wong
2026-07-02 22:41 ` Joanne Koong
2026-07-01 0:09 ` [PATCH v2 02/18] xfs: convert iomap ops to ->iomap_next() Joanne Koong
2026-07-02 14:03 ` Christoph Hellwig
2026-07-02 16:48 ` Darrick J. Wong
2026-07-03 12:33 ` Christoph Hellwig
2026-07-03 15:50 ` Darrick J. Wong
2026-07-02 16:43 ` Darrick J. Wong [this message]
2026-07-02 23:59 ` Joanne Koong
2026-07-03 1:21 ` Joanne Koong
2026-07-03 1:41 ` Darrick J. Wong
2026-07-03 12:32 ` Christoph Hellwig
2026-07-03 1:38 ` Darrick J. Wong
2026-07-01 0:09 ` [PATCH v2 03/18] btrfs: " Joanne Koong
2026-07-01 0:09 ` [PATCH v2 04/18] ntfs3: " Joanne Koong
2026-07-01 0:09 ` [PATCH v2 05/18] ntfs: " Joanne Koong
2026-07-01 0:09 ` [PATCH v2 06/18] ext4: " Joanne Koong
2026-07-01 10:01 ` Jan Kara
2026-07-01 0:09 ` [PATCH v2 07/18] erofs: " Joanne Koong
2026-07-01 0:41 ` Gao Xiang
2026-07-01 0:09 ` [PATCH v2 08/18] zonefs: " Joanne Koong
2026-07-01 0:09 ` [PATCH v2 09/18] ext2: " Joanne Koong
2026-07-01 10:02 ` Jan Kara
2026-07-01 0:09 ` [PATCH v2 10/18] block: " Joanne Koong
2026-07-01 0:55 ` Keith Busch
2026-07-02 14:03 ` Christoph Hellwig
2026-07-03 0:06 ` Joanne Koong
2026-07-01 0:09 ` [PATCH v2 11/18] f2fs: " Joanne Koong
2026-07-01 0:09 ` [f2fs-dev] " Joanne Koong
2026-07-01 0:09 ` [PATCH v2 12/18] gfs2: " Joanne Koong
2026-07-03 11:45 ` Andreas Gruenbacher
2026-07-04 0:07 ` Joanne Koong
2026-07-01 0:09 ` [PATCH v2 13/18] hpfs: " Joanne Koong
2026-07-01 0:09 ` [PATCH v2 14/18] fuse: " Joanne Koong
2026-07-01 0:09 ` [PATCH v2 15/18] exfat: " Joanne Koong
2026-07-03 1:41 ` Joanne Koong
2026-07-01 0:09 ` [PATCH v2 16/18] iomap: remove ->iomap_begin()/->iomap_end() legacy path Joanne Koong
2026-07-02 14:04 ` Christoph Hellwig
2026-07-02 16:51 ` Darrick J. Wong
2026-07-01 0:09 ` [PATCH v2 17/18] iomap: pass iomap_next_fn directly instead of struct iomap_ops Joanne Koong
2026-07-01 0:09 ` [f2fs-dev] " Joanne Koong
2026-07-01 10:04 ` Jan Kara
2026-07-01 10:04 ` [f2fs-dev] " Jan Kara
2026-07-02 14:07 ` Christoph Hellwig
2026-07-02 14:07 ` [f2fs-dev] " Christoph Hellwig
2026-07-02 16:51 ` Darrick J. Wong
2026-07-02 16:51 ` [f2fs-dev] " Darrick J. Wong via Linux-f2fs-devel
2026-07-03 1:47 ` Joanne Koong
2026-07-03 1:47 ` [f2fs-dev] " Joanne Koong
2026-07-03 2:01 ` Darrick J. Wong via Linux-f2fs-devel
2026-07-03 2:01 ` Darrick J. Wong
2026-07-03 10:37 ` Christian Brauner
2026-07-03 10:37 ` [f2fs-dev] " Christian Brauner via Linux-f2fs-devel
2026-07-02 16:58 ` Darrick J. Wong
2026-07-02 16:58 ` [f2fs-dev] " Darrick J. Wong via Linux-f2fs-devel
2026-07-03 0:17 ` Joanne Koong
2026-07-03 0:17 ` [f2fs-dev] " Joanne Koong
2026-07-03 1:42 ` Darrick J. Wong
2026-07-03 1:42 ` [f2fs-dev] " Darrick J. Wong via Linux-f2fs-devel
2026-07-01 0:09 ` [PATCH v2 18/18] Documentation: iomap: update docs to reflect iomap_next model Joanne Koong
2026-07-02 14:07 ` Christoph Hellwig
2026-07-02 19:26 ` Darrick J. Wong
2026-07-03 1:36 ` Joanne Koong
2026-07-03 2:00 ` Darrick J. Wong
2026-07-03 12:43 ` Christoph Hellwig
2026-07-03 16:11 ` Darrick J. Wong
2026-07-04 0:34 ` Joanne Koong
2026-07-04 4:38 ` Darrick J. Wong
2026-07-06 4:59 ` Christoph Hellwig
2026-07-06 3:59 ` Christoph Hellwig
2026-07-06 3:56 ` Christoph Hellwig
2026-07-02 13:49 ` [PATCH v2 00/18] iomap: convert to in-iter iomap_next() model Christoph Hellwig
2026-07-03 1:08 ` Joanne Koong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260702164339.GI9392@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=brauner@kernel.org \
--cc=cem@kernel.org \
--cc=hch@lst.de \
--cc=hsiangkao@linux.alibaba.com \
--cc=joannelkoong@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.