linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Baron <jbaron@akamai.com>
To: Jim Cromie <jim.cromie@gmail.com>,
	linux-kernel@vger.kernel.org, akpm@linuxfoundation.org,
	gregkh@linuxfoundation.org
Cc: linux@rasmusvillemoes.dk
Subject: Re: [PATCH 00/16] dynamic_debug: cleanups, 2 features
Date: Fri, 12 Jun 2020 17:31:22 -0400	[thread overview]
Message-ID: <8f106309-8d7b-5bfc-6f8b-7223a3a1c72c@akamai.com> (raw)
In-Reply-To: <20200605162645.289174-1-jim.cromie@gmail.com>



On 6/5/20 12:26 PM, Jim Cromie wrote:
> Patchset starts with 7 "cleanups";
> - it changes section name from vague "__verbose" to "__dyndbg"
> - cleaner docs, drop obsolete comment & useless debug prints, refine
>   verbosity, fix a BUG_ON, ram reporting miscounts.
> 
> It adds a few query parsing conveniences;
> accept combined file:line & file:func forms
> 
>   file inode.c:100-200		# file & line-range
>   file inode.c:start_*		# file & function
>

So I like the shortened notation there.

> Then it expands flags:
> 
> Adds 'u' user flag, allowing user to compose an arbitrary set of
> callsites by marking them with 'u', without altering current
> print-modifying flags.
> 
> Adds 'PFMLTU' flags, which negate their lower-case counterparts.
> 
> Extends flags-spec with filter-flags, which select callsites for
> modification based upon their current flags.  This lets user activate
> the set of callsites marked with 'u' in a batch.
> 
>   echo 'u+p' > control
> 

I'm wondering if users are really going to use these and how much they
simplify things? Do you find them useful while debugging issues?

Especially now that now that we are looking to let people define
groupings.

Thanks,

-Jason

  parent reply	other threads:[~2020-06-12 21:32 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-05 16:26 [PATCH 00/16] dynamic_debug: cleanups, 2 features Jim Cromie
2020-06-05 16:26 ` [PATCH 01/16] dyndbg-docs: eschew file /full/path query in docs Jim Cromie
2020-06-05 16:26 ` [PATCH 02/16] dyndbg: drop obsolete comment on ddebug_proc_open Jim Cromie
2020-06-05 16:26 ` [PATCH 03/16] dyndbg: refine debug verbosity; 1 is basic, 2 more chatty Jim Cromie
2020-06-08 11:21   ` Daniel Thompson
2020-06-09 19:59     ` jim.cromie
2020-06-10 11:16       ` Daniel Thompson
2020-06-10 13:45         ` jim.cromie
2020-06-05 16:26 ` [PATCH 04/16] dyndbg: rename __verbose section to __dyndbg Jim Cromie
2020-06-05 16:26 ` [PATCH 05/16] dyndbg: fix overcounting of ram used by dyndbg Jim Cromie
2020-06-05 16:26 ` [PATCH 06/16] dyndbg: fix a BUG_ON in ddebug_describe_flags Jim Cromie
2020-06-05 16:26 ` [PATCH 07/16] dyndbg: make ddebug_tables list LIFO for add/remove_module Jim Cromie
2020-06-05 16:26 ` [PATCH 08/16] dyndbg: refactor parse_linerange out of ddebug_parse_query Jim Cromie
2020-06-05 16:26 ` [PATCH 09/16] dyndbg: accept 'file foo.c:func1' and 'file foo.c:10-100' Jim Cromie
2020-06-12 20:36   ` Jason Baron
2020-06-05 16:26 ` [PATCH 10/16] dyndbg: refactor ddebug_read_flags out of ddebug_parse_flags Jim Cromie
2020-06-05 16:26 ` [PATCH 11/16] dyndbg: combine flags & mask into a struct, use that Jim Cromie
2020-06-05 16:26 ` [PATCH 12/16] dyndbg: add filter parameter to ddebug_parse_flags Jim Cromie
2020-06-12 21:05   ` Jason Baron
2020-06-05 16:26 ` [PATCH 13/16] dyndbg: extend ddebug_parse_flags to accept optional leading filter-flags Jim Cromie
2020-06-05 16:26 ` [PATCH 14/16] dyndbg: prefer declarative init in caller, to memset in callee Jim Cromie
2020-06-05 16:26 ` [PATCH 15/16] dyndbg: add user-flag, negating-flags, and filtering on flags Jim Cromie
2020-06-05 16:26 ` [PATCH 16/16] dyndbg: allow negating flag-chars in modflags Jim Cromie
2020-06-12 21:31 ` Jason Baron [this message]
2020-06-13  2:19   ` [PATCH 00/16] dynamic_debug: cleanups, 2 features jim.cromie

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=8f106309-8d7b-5bfc-6f8b-7223a3a1c72c@akamai.com \
    --to=jbaron@akamai.com \
    --cc=akpm@linuxfoundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jim.cromie@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    /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).