From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: song@kernel.org, linux-kernel@vger.kernel.org,
linux-raid@vger.kernel.org, yukuai3@huawei.com,
yi.zhang@huawei.com, yangerkun@huawei.com
Subject: Re: [PATCH RFC -next 01/26] md/md-bitmap: introduce struct bitmap_operations
Date: Tue, 13 Aug 2024 08:58:54 +0200 [thread overview]
Message-ID: <20240813085806.00006ec3@linux.intel.com> (raw)
In-Reply-To: <20240810020854.797814-2-yukuai1@huaweicloud.com>
On Sat, 10 Aug 2024 10:08:29 +0800
Yu Kuai <yukuai1@huaweicloud.com> wrote:
> From: Yu Kuai <yukuai3@huawei.com>
>
> The structure is empty for now, and will be used in later patches to
> merge in bitmap operations, prepare to implement a new lock free
> bitmap in the fulture.
HI Kuai,
typo: future
I think that as "later" you meant next patches in this patchset, right? If yes,
Please you "next" instead.
At this point bringing "lock free implementation in the future" looks like
totally unnecessary. It may happen or may not. Eventually, You can mention it in
cover letter. What we have now is the most important.
This is just a code rework. The main goal of this (as you mentioned in second
patch):
"So that the implementation won't be exposed, and it'll be possible
to invent a new bitmap by replacing bitmap_operations."
but please mention that you are not going to implement second mechanism to not
confuse reader. You need it to improve code maintainability mainly I think.
I would mention something about common "struct _ops" pattern (the special
structure to keep related operations together) that it is going to follow now.
For me, this one can be easy merged with the patch 2, so we will got struct +
usage in one patch.
Anyway, LGTM.
Thanks,
Mariusz
next prev parent reply other threads:[~2024-08-13 6:59 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-10 2:08 [PATCH RFC -next 00/26] md/md-bitmap: introduce bitmap_operations Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 01/26] md/md-bitmap: introduce struct bitmap_operations Yu Kuai
2024-08-13 6:58 ` Mariusz Tkaczyk [this message]
2024-08-13 7:25 ` Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 02/26] md/md-bitmap: merge md_bitmap_create() into bitmap_operations Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 03/26] md/md-bitmap: merge md_bitmap_load() " Yu Kuai
2024-08-13 7:07 ` Mariusz Tkaczyk
2024-08-13 7:30 ` Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 04/26] md/md-bitmap: merge md_bitmap_destroy() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 05/26] md/md-bitmap: merge md_bitmap_flush() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 06/26] md/md-bitmap: don't expose md_bitmap_print_sb() Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 07/26] md/md-bitmap: merge md_bitmap_update_sb() into bitmap_operations Yu Kuai
2024-08-13 7:17 ` Mariusz Tkaczyk
2024-08-13 7:33 ` Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 08/26] md/md-bitmap: merge md_bitmap_status() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 09/26] md/md-bitmap: remove md_bitmap_setallbits() Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 10/26] md/md-bitmap: merge bitmap_write_all() into bitmap_operations Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 11/26] md/md-bitmap: merge md_bitmap_dirty_bits() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 12/26] md/md-bitmap: merge md_bitmap_startwrite() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 13/26] md/md-bitmap: merge md_bitmap_endwrite() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 14/26] md/md-bitmap: merge md_bitmap_start_sync() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 15/26] md/md-bitmap: merge md_bitmap_end_sync() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 16/26] md/md-bitmap: merge md_bitmap_close_sync() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 17/26] md/md-bitmap: mrege md_bitmap_cond_end_sync() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 18/26] md/md-bitmap: merge bitmap_sync_with_cluster() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 19/26] md/md-bitmap: merge md_bitmap_resize() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 20/26] md/md-bitmap: merge get_bitmap_from_slot() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 21/26] md/md-bitmap: merge md_bitmap_copy_from_slot() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 22/26] md/md-bitmap: merge md_bitmap_free() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 23/26] md/md-bitmap: merge md_bitmap_wait_behind_writes() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 24/26] md/md-bitmap: merge md_bitmap_daemon_work() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 25/26] md/md-bitmap: merge md_bitmap_unplug() and md_bitmap_unplug_async() Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 26/26] md/md-bitmap: merge bitmap_unplug() into bitmap_operations Yu Kuai
2024-08-13 7:21 ` [PATCH RFC -next 00/26] md/md-bitmap: introduce bitmap_operations Christoph Hellwig
2024-08-13 7:36 ` Yu Kuai
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=20240813085806.00006ec3@linux.intel.com \
--to=mariusz.tkaczyk@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=song@kernel.org \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai1@huaweicloud.com \
--cc=yukuai3@huawei.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