From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2 4/5] btrfs: introduce btrfs_bio_for_each_block_all() helper
Date: Mon, 8 Sep 2025 19:44:38 +0200 [thread overview]
Message-ID: <20250908174438.GS5333@suse.cz> (raw)
In-Reply-To: <87f75733-f6a6-46cb-b5af-f574314342bd@suse.com>
On Sat, Sep 06, 2025 at 07:38:27AM +0930, Qu Wenruo wrote:
> >> +static inline struct bvec_iter init_bvec_iter_for_bio(struct bio *bio)
> >> +{
> >> + struct bio_vec *bvec;
> >> + u32 bio_size = 0;
> >> + int i;
> >> +
> >> + bio_for_each_bvec_all(bvec, bio, i)
> >> + bio_size += bvec->bv_len;
> >> +
> >> + return (struct bvec_iter) {
> >> + .bi_sector = 0,
> >> + .bi_size = bio_size,
> >> + .bi_idx = 0,
> >> + .bi_bvec_done = 0,
> >> + };
> >
> > We don't use this kind of initializers, usually the structure is passed
> > as parameter, but I can see how it makes it convenient in the for()
> > initialization. The parameter way would work but would also look strange
> > so I think it's acceptable.
>
> I'd say this really makes a lot of things easier, and avoid pointer
> usage (in this particular case it allows us to use local @iter without
> the need of a caller provided pointer), it should get more usage.
If the patterns are an improvement (and this means for the people who
work on the code) then we can do it, also because the minimum version of
compilers is increasing over time which means newer C features are
available. This one in particular is not new and looks readable, so ok
for me.
next prev parent reply other threads:[~2025-09-08 17:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 9:02 [PATCH v2 0/5] btrfs: bs > ps support preparation Qu Wenruo
2025-09-02 9:02 ` [PATCH v2 1/5] btrfs: support all block sizes which is no larger than page size Qu Wenruo
2025-09-02 9:02 ` [PATCH v2 2/5] btrfs: concentrate highmem handling for data verification Qu Wenruo
2025-09-02 9:02 ` [PATCH v2 3/5] btrfs: introduce btrfs_bio_for_each_block() helper Qu Wenruo
2025-09-02 9:02 ` [PATCH v2 4/5] btrfs: introduce btrfs_bio_for_each_block_all() helper Qu Wenruo
2025-09-05 17:33 ` David Sterba
2025-09-05 22:08 ` Qu Wenruo
2025-09-08 17:44 ` David Sterba [this message]
2025-09-02 9:02 ` [PATCH v2 5/5] btrfs: cache max and min order inside btrfs_fs_info Qu Wenruo
2025-09-05 17:36 ` David Sterba
2025-09-06 8:47 ` Qu Wenruo
2025-09-05 17:47 ` [PATCH v2 0/5] btrfs: bs > ps support preparation David Sterba
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=20250908174438.GS5333@suse.cz \
--to=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@suse.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox