linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Nikolay Borisov <nborisov@suse.com>, Qu Wenruo <wqu@suse.com>,
	linux-btrfs@vger.kernel.org
Subject: About enum convert (Old "Re: [PATCH 1/8] btrfs: delayed-ref: Introduce better documented delayed ref structures")
Date: Wed, 12 Dec 2018 13:09:00 +0800	[thread overview]
Message-ID: <61926f61-2f34-2636-74ed-bcb04bb969fb@gmx.com> (raw)
In-Reply-To: <235ca34f-bcda-128d-dc3d-7465766271c7@suse.com>



On 2018/12/10 下午5:48, Nikolay Borisov wrote:
> 
> 
[snip]
> 
> IMO it makes sense in this series to have a patch which converts the
> action defines to an enum and subsequently modify functions/structs to
> actually be of enum type.
> 

I'm completely OK to convert it to enum, for its conflict free nature.

However I'm not sure to which degree we should go.

For current David's enum cleanup, we all go anonymous enum, which just
acts as an auto-increasing #define.
However AFAIK compiler can further compress the size of named enum if
needed, and it provides much better type check to prevent us to do
stupid type convert.

I'm wondering which way should we go. The named enum (which needs to
modify all parameters) or anonymous enum for less code modification?

Thanks,
Qu

  parent reply	other threads:[~2018-12-12  5:09 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06  6:58 [PATCH 0/8] btrfs: Refactor delayed ref parameter list Qu Wenruo
2018-12-06  6:58 ` [PATCH 1/8] btrfs: delayed-ref: Introduce better documented delayed ref structures Qu Wenruo
2018-12-10  9:48   ` Nikolay Borisov
2018-12-10 11:20     ` Qu Wenruo
2018-12-10 11:32       ` Nikolay Borisov
2018-12-10 11:37         ` Qu Wenruo
2018-12-10 17:03           ` David Sterba
2018-12-12  5:09     ` Qu Wenruo [this message]
2018-12-06  6:58 ` [PATCH 2/8] btrfs: extent-tree: Open-code process_func in __btrfs_mod_ref Qu Wenruo
2018-12-07 17:39   ` Nikolay Borisov
2018-12-06  6:58 ` [PATCH 3/8] btrfs: delayed-ref: Use btrfs_ref to refactor btrfs_add_delayed_tree_ref() Qu Wenruo
2018-12-10  9:21   ` Nikolay Borisov
2018-12-12  5:50     ` Qu Wenruo
2018-12-06  6:58 ` [PATCH 4/8] btrfs: delayed-ref: Use btrfs_ref to refactor btrfs_add_delayed_data_ref() Qu Wenruo
2018-12-10  9:23   ` Nikolay Borisov
2018-12-06  6:59 ` [PATCH 5/8] btrfs: ref-verify: Use btrfs_ref to refactor btrfs_ref_tree_mod() Qu Wenruo
2018-12-06  6:59 ` [PATCH 6/8] btrfs: extent-tree: Use btrfs_ref to refactor add_pinned_bytes() Qu Wenruo
2018-12-10  9:45   ` Nikolay Borisov
2018-12-06  6:59 ` [PATCH 7/8] btrfs: extent-tree: Use btrfs_ref to refactor btrfs_inc_extent_ref() Qu Wenruo
2018-12-10  9:52   ` Nikolay Borisov
2018-12-10 17:28     ` David Sterba
2018-12-11  2:02       ` Qu Wenruo
2018-12-06  6:59 ` [PATCH 8/8] btrfs: extent-tree: Use btrfs_ref to refactor btrfs_free_extent() Qu Wenruo

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=61926f61-2f34-2636-74ed-bcb04bb969fb@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    --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;
as well as URLs for NNTP newsgroup(s).