All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Nikolay Borisov <nborisov@suse.com>
Cc: Josef Bacik <josef@toxicpanda.com>,
	linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH v4 4/6] btrfs: handle device lookup with btrfs_dev_lookup_args
Date: Wed, 13 Oct 2021 20:23:13 +0200	[thread overview]
Message-ID: <20211013182313.GJ9286@twin.jikos.cz> (raw)
In-Reply-To: <cbc1df4a-d7bf-3c34-4c5c-c093512c08bf@suse.com>

On Wed, Oct 06, 2021 at 10:34:41AM +0300, Nikolay Borisov wrote:
> >  int btrfs_init_dev_replace(struct btrfs_fs_info *fs_info)
> >  {
> > +	BTRFS_DEV_LOOKUP_ARGS(args);
> 
> nit: This line can be:
> 
> struct btrfs_dev_lookup_args args = {.devid = BTRFS_DEV_REPLACE_DEVID};
> 
> as it doesn't go over the 76 char limit, the only reason I'm suggesting

The limit is 80-85.

> it is for consistency sake, since in
> btrfs_scrub_progress/btrfs_scrub_dev the latter style is preferred.

Agreed, after seeing the rest of the patchset, if the members (most
often devid) can be set right away like from the parameters, the
explicit initialization should be used, so I've switched it to what
you've suggested.

> > +static inline bool dev_args_match_fs_devices(struct btrfs_dev_lookup_args *args,

Btw static inline that's not in a header does not make much sense, so
it's plain static. Also for read-only parameters it's a good habit to
declare them const, also changed.

> > +					     struct btrfs_fs_devices *fs_devices)
> > +{
> > +	if (args->fsid == NULL)
> > +		return true;
> > +	if (!memcmp(fs_devices->metadata_uuid, args->fsid, BTRFS_FSID_SIZE))
> > +		return true;
> > +	return false;
> 
> Make last 3 lines into:
> 
> return !memcmp(fs_devices->metadata_uuid, args->fsid, BTRFS_FSID_SIZE)

I really don't like the short form where memcmp (or strcmp for that
matter) is done like !memcmp as it reads "if the don't compare as
equeal" and requires the mental switch to if memcmp() == 0 "they're
equal", so I've been switching that to the == 0 form whenever I see it.

In this function, if ther's a chain of if/if/return, it reads better if
all the branches are either implicit or explicit, so mixing both styles
is slightly less preferred.

> > @@ -517,7 +530,7 @@ int btrfs_num_copies(struct btrfs_fs_info *fs_info, u64 logical, u64 len);
> >  int btrfs_grow_device(struct btrfs_trans_handle *trans,
> >  		      struct btrfs_device *device, u64 new_size);
> >  struct btrfs_device *btrfs_find_device(struct btrfs_fs_devices *fs_devices,
> > -				       u64 devid, u8 *uuid, u8 *fsid);
> > +				       struct btrfs_dev_lookup_args *args);
> 
> Let's annotate this pointer with const to be more explicit about this
> being really an input-only struct.

Agreed, const added.

  reply	other threads:[~2021-10-13 18:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 20:12 [PATCH v4 0/6] Fix lockdep issues around device removal Josef Bacik
2021-10-05 20:12 ` [PATCH v4 1/6] btrfs: use num_device to check for the last surviving seed device Josef Bacik
2021-10-05 20:12 ` [PATCH v4 2/6] btrfs: add comments for device counts in struct btrfs_fs_devices Josef Bacik
2021-10-05 20:12 ` [PATCH v4 3/6] btrfs: do not call close_fs_devices in btrfs_rm_device Josef Bacik
2021-10-06  6:40   ` Nikolay Borisov
2021-10-13 17:47     ` David Sterba
2021-10-06  8:55   ` Anand Jain
2021-10-05 20:12 ` [PATCH v4 4/6] btrfs: handle device lookup with btrfs_dev_lookup_args Josef Bacik
2021-10-06  7:34   ` Nikolay Borisov
2021-10-13 18:23     ` David Sterba [this message]
2021-10-06  8:58   ` Anand Jain
2021-10-05 20:12 ` [PATCH v4 5/6] btrfs: add a btrfs_get_dev_args_from_path helper Josef Bacik
2021-10-06  8:24   ` Nikolay Borisov
2021-10-06  8:58   ` Anand Jain
2021-10-05 20:12 ` [PATCH v4 6/6] btrfs: use btrfs_get_dev_args_from_path in dev removal ioctls Josef Bacik
2021-10-06  8:54   ` Anand Jain
2021-10-06  9:05     ` Nikolay Borisov
2021-10-19  3:42       ` Anand Jain
2021-10-18 15:22 ` [PATCH v4 0/6] Fix lockdep issues around device removal 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=20211013182313.GJ9286@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=josef@toxicpanda.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@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.