All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Anand Jain <anand.jain@oracle.com>
Cc: dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 6/6] btrfs: refactor btrfs_find_device() return error code
Date: Fri, 18 Jan 2019 18:20:57 +0100	[thread overview]
Message-ID: <20190118172056.GC2900@twin.jikos.cz> (raw)
In-Reply-To: <8e14c714-d869-f8a8-9832-610313d2254b@oracle.com>

On Fri, Jan 18, 2019 at 02:13:26PM +0800, Anand Jain wrote:
> 
> 
> On 01/17/2019 11:49 PM, David Sterba wrote:
> > On Thu, Jan 17, 2019 at 11:32:33PM +0800, Anand Jain wrote:
> >> Refactor btrfs_find_device() to return standard error code.
> > 
> > Do you intend to add more error codes?
> 
>   No actually.
> 
>   code like this ...
>      if (PTR_ERR(device) == -ENOENT)
>   can be
>      if (IS_ERR(device))
> 
> 
> > A NULL is valid in case it's
> > clear that it always means 'device not found'.
> > 
> 
>   Oh. I am not too particular, I am ok to drop this patch.
> 
>   The thought process was.. having btrfs_find_device() to return standard
>   err code made code at @@ -2404,8 +2404,6 @@; @@ -2419,13 +2417,9 @@;
>   simpler.

Well, that piece of code is simpler but when compared to the amount of
other changes in the rest it's not making it simpler.

>   And as ioctls already return -ENODEV (though it might not be correct
>   one),

Unrelated to this patch, but I tend to agree that ENODEV is wrong.
However it's been in use for a long time so we can't change easily.

>   so if btrfs_find_device() could return -ENODEV (instead of
>   -ENOENT) then there are few more places where code can be just ..
>      if (IS_ERR(device))
> 	return PTR_ERR(device);

I've seen a lot return values of btrfs_find_device are for internal
purposes so the translation from NULL pointer to ENODEV/ENOENT does not
happen that often. In some contexts it's even something different like
EUCLEAN, but I maybe see the motivation to change it to ERR_PTR, as
btrfs_find_device_by_devspec and btrfs_find_device_missing_or_by_path
return that - btrfs_find_device is different here.

  reply	other threads:[~2019-01-18 17:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-17 15:32 [PATCH 0/6] btrfs: find_device cleanups Anand Jain
2019-01-17 15:32 ` [PATCH 1/6] btrfs: merge btrfs_find_device_missing_or_by_path() into parent Anand Jain
2019-01-17 15:57   ` David Sterba
2019-01-17 15:32 ` [PATCH 2/6] btrfs: cleanup btrfs_find_device_by_devspec() Anand Jain
2019-01-17 15:57   ` David Sterba
2019-01-17 15:32 ` [PATCH 3/6] btrfs: rename btrfs_find_device_by_path() Anand Jain
2019-01-17 15:54   ` David Sterba
2019-01-18  6:13     ` Anand Jain
2019-01-18 17:05       ` David Sterba
2019-01-17 15:32 ` [PATCH 4/6] btrfs: refactor btrfs_find_device() take fs_devices as argument Anand Jain
2019-01-17 15:58   ` David Sterba
2019-01-17 15:32 ` [PATCH 5/6] btrfs: merge btrfs_find_device() and find_device() Anand Jain
2019-01-17 15:51   ` David Sterba
2019-01-19  6:48   ` [PATCH 5/6 v2] " Anand Jain
2019-01-23  5:28     ` Anand Jain
2019-01-28 18:44     ` David Sterba
2019-01-17 15:32 ` [PATCH 6/6] btrfs: refactor btrfs_find_device() return error code Anand Jain
2019-01-17 15:49   ` David Sterba
2019-01-18  6:13     ` Anand Jain
2019-01-18 17:20       ` David Sterba [this message]
2019-01-18 17:33 ` [PATCH 0/6] btrfs: find_device cleanups David Sterba
2019-01-19  6:54   ` Anand Jain

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=20190118172056.GC2900@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=anand.jain@oracle.com \
    --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 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.