All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/6] iomap: support incremental iomap_iter advances
Date: Wed, 8 Jan 2025 23:07:22 -0800	[thread overview]
Message-ID: <Z391qhtj_c56nfc2@infradead.org> (raw)
In-Reply-To: <20241213143610.1002526-4-bfoster@redhat.com>

On Fri, Dec 13, 2024 at 09:36:07AM -0500, Brian Foster wrote:
> Note that the semantics for operations that use incremental advances
> is slightly different than traditional operations. Operations that
> advance the iter directly are expected to return success or failure
> (i.e. 0 or negative error code) in iter.processed rather than the
> number of bytes processed.

While the uses of the incremental advance later look nice, this bit
is pretty ugly.  I wonder if we could just move overy everything to
the incremental advance model, even if it isn't all that incremental,
that is always call iomap_iter_advance from the processing loop and
eventually remove the call in iomap_iter() entirely?

> @@ -36,7 +36,7 @@ static inline int iomap_iter_advance(struct iomap_iter *iter, s64 count)
>  		return -EIO;
>  	iter->pos += count;
>  	iter->len -= count;
> -	if (!iter->len || (!count && !stale))
> +	if (!iter->len || (!count && !stale && iomap_length(iter)))

This probably warrantd a comment even with the existing code, but really
needs one now.

> + * @iter_spos: The original start pos for the current iomap. Used for
> + *	incremental iter advance.

Maybe spell out the usage as iter_start_pos in the field name as spos
reads a little weird?


  reply	other threads:[~2025-01-09  7:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-13 14:36 [PATCH 0/6] iomap: incremental per-operation iter advance Brian Foster
2024-12-13 14:36 ` [PATCH 1/6] iomap: split out iomap check and reset logic from " Brian Foster
2025-01-09  7:00   ` Christoph Hellwig
2024-12-13 14:36 ` [PATCH 2/6] iomap: factor out iomap length helper Brian Foster
2025-01-09  7:02   ` Christoph Hellwig
2025-01-10 17:49     ` Brian Foster
2025-01-13  4:46       ` Christoph Hellwig
2024-12-13 14:36 ` [PATCH 3/6] iomap: support incremental iomap_iter advances Brian Foster
2025-01-09  7:07   ` Christoph Hellwig [this message]
2025-01-10 17:50     ` Brian Foster
2025-01-13  4:48       ` Christoph Hellwig
2025-01-13 14:25         ` Brian Foster
2024-12-13 14:36 ` [PATCH 4/6] iomap: advance the iter directly on buffered writes Brian Foster
2025-01-09  7:10   ` Christoph Hellwig
2025-01-10 17:51     ` Brian Foster
2025-01-15  5:46       ` Christoph Hellwig
2024-12-13 14:36 ` [PATCH 5/6] iomap: advance the iter directly on unshare range Brian Foster
2024-12-13 14:36 ` [PATCH 6/6] iomap: advance the iter directly on zero range Brian Foster

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=Z391qhtj_c56nfc2@infradead.org \
    --to=hch@infradead.org \
    --cc=bfoster@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.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.