linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v3] btrfs-progs: add verbose option to btrfs device scan
Date: Tue, 15 Oct 2019 11:29:34 +0800	[thread overview]
Message-ID: <365faddf-cf4f-2a03-820d-d4f5071240e8@oracle.com> (raw)
In-Reply-To: <20191014152457.GQ2751@twin.jikos.cz>

On 10/14/19 11:24 PM, David Sterba wrote:
> On Tue, Oct 08, 2019 at 10:53:37AM +0800, Anand Jain wrote:
>> On 10/8/19 1:41 AM, David Sterba wrote:
>>> On Wed, Oct 02, 2019 at 12:11:52PM +0800, Anand Jain wrote:
>>>> To help debug device scan issues, add verbose option to btrfs device scan.
>>>
>>> The common options like --verbose are going to be added into the global
>>> command so I'd rather avoid adding them to new subcommands as this would
>>> become unnecessary compatibility issue.
>>
>>> There's an pattern to follow, the output formats (--format). So add a
>>> definition for global verbosity options, add new GETOPT_VAL global enum
>>> values that do not clash with existing options, add relevant
>>> HELPINFO_INSERT_ text string and use it in commands where needed.
>>>
>>
>>    IMO a debug option should rather be at the top level command.
>>    If verbose is the top level it would emit a lot of unwanted messages.
>>    Here is how a user is using --verbose option in dev scan.
>>
>>   
>> https://lore.kernel.org/linux-btrfs/2daf15de-d1e7-b56a-be51-a6a3062ad28a@oracle.com/T/#t
>>
>> ------------
>> useful to get the list of devices it finds.
>> ------------
>>
>>    OR I didn't get the whole idea here. Looks like you are suggesting
>>    something like
>>
>>     btrfs --verbose device scan
>>     btrfs --verbose subvolume list <mnt>
> 
> Yes this is what I mean.
> 
>>     ::
>>
>>    How does the user will know if a subcommand will have any verbose
>>    or not?
> 
> The point is that the global option will work for all subcommands, so
> the user does not have to know which support that or not. For
> compatiblity reasons, what works now will continue to work. This means
> that the verbosity option will be duplicated for some commands.
> 
>>    How would you not emit unwanted messages and keep the output clutter
>>    free.
> 
> What unwanted messages? Though the verbosity option will be set as
> global option, it will be up to the command itself what to print.
> 
>    $ btrfs -v device scan
> 
> would be equivalent to
> 
>    $ btrfs device scan -v
> 

  I was thinking there might be some common code between the
  sub-commands in btrfs-progs now or in future, and if the printf()
  due to verbose is required in one sub-command and the same printf()
  due to verbose is not required in another sub-command (which I
  called unwanted message) then we won't have any choice to not
  to print those unwanted printf().
  But as this is just an anticipatory only, so probably we could try
  global verbose and see how it fares. I will try.

Thanks, Anand


  reply	other threads:[~2019-10-15  3:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-02  4:11 [PATCH v3] btrfs-progs: add verbose option to btrfs device scan Anand Jain
2019-10-02  4:44 ` [PATCH v3.1] " Anand Jain
2019-10-07 17:41 ` [PATCH v3] " David Sterba
2019-10-08  2:53   ` Anand Jain
2019-10-14 15:24     ` David Sterba
2019-10-15  3:29       ` Anand Jain [this message]
2019-10-21 13:43         ` David Sterba
2019-10-21 23:48           ` 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=365faddf-cf4f-2a03-820d-d4f5071240e8@oracle.com \
    --to=anand.jain@oracle.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 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).