All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: dsterba@suse.cz, Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
	Qu Wenruo <wqu@suse.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] btrfs: use ilog2() to replace if () branches for btrfs_bg_flags_to_raid_index()
Date: Thu, 21 Apr 2022 07:01:43 +0800	[thread overview]
Message-ID: <730fff0b-faca-9792-b7f1-47b4bf48570a@gmx.com> (raw)
In-Reply-To: <20220420151631.GF1513@twin.jikos.cz>



On 2022/4/20 23:16, David Sterba wrote:
> On Wed, Apr 20, 2022 at 08:41:13AM +0000, Johannes Thumshirn wrote:
>> On 20/04/2022 10:38, Qu Wenruo wrote:
>>>>> 1. Make sure RAID0 is always the lowest bit in PROFILE_MASK
>>>>>      This is done by finding the first (least significant) bit set of
>>>>>      RAID0 and PROFILE_MASK & ~RAID0.
>>>>>
>>>>> 2. Make sure RAID0 bit set beyond the highest bit of TYPE_MASK
>>>>
>>>> TBH I think this change obscures the code more than it improves it.
>>>>
>>> Right, that kinda makes sense.
>>>
>>> Will update the patchset to remove that line if needed.
>>
>> I think the whole patch makes the code harder to follow. As of now you can
>> just look it up, now you have to look how the calculation is done etc.
>
> I think the index is the least useful information about the profiles,
> it's there just that we have a sequence representing the profile flags
> that's usable for arrays, like the space infos. The on-disk definition
> is the bit and that's the source, how exactly it's converted to the
> index is IMHO just a detail.
>
>> If you want to get rid of the branches (which I still don't see a reason for)
>> have you considered creating a lookup table?
>
> It's yet another place that keeps the mapping of the values open coded.
>
> Possibly if we would want to take it farther, a single definition of the
> index enums could be like
>
> #define	DEFINE_RAID_INDEX(profile)				\
> 	BTRFS_RAID_##profile   = BTRFS_BG_FLAG_TO_INDEX(BTRFS_BLOCK_GROUP_##profile)
>
> and then used like
>
> enum raid_types {
> 	DEFINE_RAID_INDEX(RAID0),
> 	DEFINE_RAID_INDEX(RAID10),
> 	...
> };
>
> But that's obscuring what exactly does it define and we do use the plain
> indexes like BTRFS_RAID_DUP in several places. It's sometimes annoying
> that ctags don't locate all the setget helpers because of all the
> BTRFS_SETGET_FUNCS macros.

Ctags are really out-of-date now.
LSP is the future, just try clangd, handling macros is just a piece of cake.

Thanks,
Qu

  reply	other threads:[~2022-04-20 23:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20  8:08 [PATCH v3 0/2] btrfs: re-define btrfs_raid_types Qu Wenruo
2022-04-20  8:08 ` [PATCH v3 1/2] btrfs: move definition of btrfs_raid_types to volumes.h Qu Wenruo
2022-04-20  8:13   ` Johannes Thumshirn
2022-04-20  8:08 ` [PATCH v3 2/2] btrfs: use ilog2() to replace if () branches for btrfs_bg_flags_to_raid_index() Qu Wenruo
2022-04-20  8:25   ` Johannes Thumshirn
2022-04-20  8:38     ` Qu Wenruo
2022-04-20  8:41       ` Johannes Thumshirn
2022-04-20  9:45         ` Qu Wenruo
2022-04-20 15:16         ` David Sterba
2022-04-20 23:01           ` Qu Wenruo [this message]
2022-04-22 20:30 ` [PATCH v3 0/2] btrfs: re-define btrfs_raid_types 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=730fff0b-faca-9792-b7f1-47b4bf48570a@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=Johannes.Thumshirn@wdc.com \
    --cc=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 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.