linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Johannes Thumshirn <jthumshirn@suse.de>
Cc: David Sterba <dsterba@suse.com>,
	Linux BTRFS Mailinglist <linux-btrfs@vger.kernel.org>
Subject: Re: [RFC PATCH 2/4] btrfs: create structure to encode checksum type and length
Date: Tue, 30 Jul 2019 19:25:36 +0200	[thread overview]
Message-ID: <20190730172536.GF28208@twin.jikos.cz> (raw)
In-Reply-To: <944b685765a68c3389888159d3fe228c2e78eb22.1564046812.git.jthumshirn@suse.de>

On Thu, Jul 25, 2019 at 11:33:49AM +0200, Johannes Thumshirn wrote:
> Create a structure to encode the type and length for the known on-disk
> checksums. Also add a table and a convenience macro for adding the
> checksum types to the table.
> 
> This makes it easier to add new checksums later.
> 
> Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
> ---
>  fs/btrfs/ctree.h | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> index da97ff10f421..099401f5dd47 100644
> --- a/fs/btrfs/ctree.h
> +++ b/fs/btrfs/ctree.h
> @@ -82,9 +82,15 @@ struct btrfs_ref;
>   */
>  #define BTRFS_LINK_MAX 65535U
>  
> -/* four bytes for CRC32 */
> -static const int btrfs_csum_sizes[] = { 4 };
> -static const char *btrfs_csum_names[] = { "crc32c" };
> +#define BTRFS_CHECKSUM_TYPE(_type, _size, _name) \
> +	[_type] = { .size = _size, .name = _name }

I think the macro initializer might be an overkill here, there are only
3 items to initialize.

> +
> +static const struct btrfs_csums {
> +	u16		size;
> +	const char	*name;
> +} btrfs_csums[] = {
> +	BTRFS_CHECKSUM_TYPE(BTRFS_CSUM_TYPE_CRC32, 4, "crc32c"),
> +};
>  
>  #define BTRFS_EMPTY_DIR_SIZE 0
>  
> @@ -2373,13 +2379,13 @@ static inline int btrfs_super_csum_size(const struct btrfs_super_block *s)
>  	/*
>  	 * csum type is validated at mount time
>  	 */
> -	return btrfs_csum_sizes[t];
> +	return btrfs_csums[t].size;
>  }
>  
>  static inline const char *btrfs_super_csum_name(u16 csum_type)
>  {
>  	/* csum type is validated at mount time */
> -	return btrfs_csum_names[csum_type];
> +	return btrfs_csums[csum_type].name;
>  }

This has been in the code already, but shouldn't the btrfs_csums table
be declared in ctree.h and defined in eg. in ctree.c? As ctree.h is
included by everything we have multiple copies of it in the .o files.

  parent reply	other threads:[~2019-07-30 17:25 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-25  9:33 [RFC PATCH 0/4] Support xxhash64 checksums Johannes Thumshirn
2019-07-25  9:33 ` [RFC PATCH 1/4] btrfs: turn checksum type define into a union Johannes Thumshirn
2019-07-25 11:08   ` Mike Fleetwood
2019-07-25 11:21     ` Johannes Thumshirn
2019-07-25  9:33 ` [RFC PATCH 2/4] btrfs: create structure to encode checksum type and length Johannes Thumshirn
2019-07-26  3:09   ` Su Yue
2019-07-30 17:25   ` David Sterba [this message]
2019-08-12  9:07   ` Nikolay Borisov
2019-08-19  9:15     ` Johannes Thumshirn
2019-07-25  9:33 ` [RFC PATCH 3/4] btrfs: use xxhash64 for checksumming Johannes Thumshirn
2019-07-25 12:02   ` Qu Wenruo
2019-07-25 14:18     ` Johannes Thumshirn
2019-07-26 13:45       ` David Sterba
2019-07-25  9:33 ` [RFC PATCH 4/4] btrfs: sysfs: export supported checksums Johannes Thumshirn
2019-07-30 17:19   ` David Sterba
2019-07-31  8:06     ` Johannes Thumshirn
2019-08-07 14:10     ` Johannes Thumshirn
2019-08-21 16:19       ` David Sterba
2019-08-12  9:19   ` Nikolay Borisov
2019-08-19  9:15     ` Johannes Thumshirn
2019-07-25  9:33 ` [RFC PATCH 05/17] btrfs-progs: add option for checksum type to mkfs Johannes Thumshirn
2019-07-30 17:36   ` David Sterba
2019-08-12  9:30   ` Nikolay Borisov
2019-07-25  9:33 ` [RFC PATCH 06/17] btrfs-progs: don't blindly assume crc32c in csum_tree_block_size() Johannes Thumshirn
2019-08-12  9:49   ` Nikolay Borisov
2019-07-25  9:33 ` [RFC PATCH 07/17] btrfs-progs: use btrfs_csum_data() in __csum_tree_block_size() Johannes Thumshirn
2019-07-30 17:37   ` David Sterba
2019-07-25  9:33 ` [RFC PATCH 08/17] btrfs-progs: cache csum_type in recover_control Johannes Thumshirn
2019-08-12  9:52   ` Nikolay Borisov
2019-07-25  9:33 ` [RFC PATCH 09/17] progs: pass in a btrfs_mkfs_config to write_temp_extent_buffer Johannes Thumshirn
2019-07-30 17:38   ` David Sterba
2019-08-12  9:56   ` Nikolay Borisov
2019-07-25  9:33 ` [RFC PATCH 10/17] btrfs-progs: add checksum type to checksumming functions Johannes Thumshirn
2019-08-12 10:21   ` Nikolay Borisov
2019-08-26  9:34     ` Johannes Thumshirn
2019-07-25  9:33 ` [RFC PATCH 11/17] btrfs-progs: don't assume checksums are always 4 bytes Johannes Thumshirn
2019-07-25  9:33 ` [RFC PATCH 12/17] btrfs-progs: pass checksum type to btrfs_csum_data() Johannes Thumshirn
2019-08-12 10:51   ` Nikolay Borisov
2019-08-20  9:12     ` Johannes Thumshirn
2019-07-25  9:34 ` [RFC PATCH 13/17] " Johannes Thumshirn
2019-07-25  9:34 ` [RFC PATCH 14/17] btrfs-progs: simplify update_block_csum() in btrfs-sb-mod.c Johannes Thumshirn
2019-08-12 10:53   ` Nikolay Borisov
2019-07-25  9:34 ` [RFC PATCH 15/17] btrfs-progs: update checksumming api Johannes Thumshirn
2019-07-25  9:34 ` [RFC PATCH 16/17] btrfs-progs: add xxhash sources Johannes Thumshirn
2019-07-25  9:34 ` [RFC PATCH 17/17] btrfs-progs: add xxhash64 as checksum algorithm Johannes Thumshirn

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=20190730172536.GF28208@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=dsterba@suse.com \
    --cc=jthumshirn@suse.de \
    --cc=linux-btrfs@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 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).