All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Holger Hoffstätte" <holger.hoffstaette@googlemail.com>
To: dsterba@suse.cz, linux-btrfs <linux-btrfs@vger.kernel.org>,
	Chris Mason <clm@fb.com>, David Sterba <dsterba@suse.com>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [PATCH] delete obsolete function btrfs_print_tree()
Date: Mon, 4 Apr 2016 17:54:42 +0200	[thread overview]
Message-ID: <57028E42.1090901@googlemail.com> (raw)
In-Reply-To: <20160404135641.GB3412@twin.jikos.cz>

On 04/04/16 15:56, David Sterba wrote:
> On Fri, Mar 25, 2016 at 03:53:17PM +0100, Holger Hoffstätte wrote:
>> Dan Carpenter's static checker recently found missing IS_ERR handling
>> in print-tree.c:btrfs_print_tree(). While looking into this I found that
>> this function is no longer called anywhere and was moved to btrfs-progs
>> long ago. It can simply be removed.
> 
> I'm not sure, the function could be used for debugging, and it's hard to

..but is it? So far nobody has complained.

> say if we'll ever need it.  Printing the whole tree to the system log
> would produce a lot of text so some manual filtering would be required,
> the function could serve as a template.

The original problem of missing error handling from btrfs_read_tree_block()
remains as well. I don't remember if that also was true for the btrfs-progs
counterpart, but in in any case I didn't really know what to do there.
Print an error? silently ignore the stripe? abort? When I realized that the
function was not called anywhere, deleting it seemed more effective.

Under what circumstances would the in-kernel function be more
practical or useful than the userland tool? It does the same, won't disturb
or wedge the kernel further, is up-to-date and can be scripted.
I agree that in-place filtering (while iterating) would be nice to have,
but that's also a whole different problem and would IMHO also be better
suited for userland.

When in doubt cut it out.

Holger


  reply	other threads:[~2016-04-04 15:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-25 14:53 [PATCH] delete obsolete function btrfs_print_tree() Holger Hoffstätte
2016-04-04 13:56 ` David Sterba
2016-04-04 15:54   ` Holger Hoffstätte [this message]
2016-04-04 16:02     ` Filipe Manana
2016-04-04 16:20       ` Holger Hoffstätte
2016-04-04 20:10       ` Dan Carpenter

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=57028E42.1090901@googlemail.com \
    --to=holger.hoffstaette@googlemail.com \
    --cc=clm@fb.com \
    --cc=dan.carpenter@oracle.com \
    --cc=dsterba@suse.com \
    --cc=dsterba@suse.cz \
    --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.