linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: jim.cromie@gmail.com
Cc: Jason Baron <jbaron@akamai.com>,
	LKML <linux-kernel@vger.kernel.org>,
	akpm@linuxfoundation.org, Greg KH <gregkh@linuxfoundation.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Jonathan Corbet <corbet@lwn.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Will Deacon <will@kernel.org>, Orson Zhai <orson.zhai@unisoc.com>,
	Linux Documentation List <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v3 19/21] dyndbg: extend ddebug_parse_flags to accept optional leading filter-flags
Date: Thu, 18 Jun 2020 18:01:29 +0200	[thread overview]
Message-ID: <20200618160129.GC3617@alley> (raw)
In-Reply-To: <CAJfuBxyw7v=uQFMLHbsP_MAub7DFZOto6SnU71upXZDcK9L9QQ@mail.gmail.com>

On Thu 2020-06-18 08:54:58, jim.cromie@gmail.com wrote:
> On Thu, Jun 18, 2020 at 6:44 AM Petr Mladek <pmladek@suse.com> wrote:
> >
> > On Wed 2020-06-17 10:25:34, Jim Cromie wrote:
> > > Change ddebug_parse_flags to accept optional filterflags before the
> > > required operator [-+=].  Read the flags into the filter_flags
> > > parameter added in the previous patch.  So this now supplies the
> > > filterflags to ddebug_exec_query.
> > >
> > > filterflags work like query terms, they constrain what callsites get
> > > matched before theyre modified.  So like a query, they can be empty.
> > >
> > > Filterflags let you read callsite's flagstate, including results of
> > > previous modifications, and require that certain flags are set, before
> > > modifying the callsite further.
> > >
> > > So you can build up sets of callsites by marking them with a
> > > particular flagstate, for example 'fmlt', then enable that set in a
> > > batch.
> > >
> > >   echo fmlt+p >control
> > >
> > > Naturally you can use almost any combo of flags you want for marking,
> > > and can mark several different sets with different patterns.  And then
> > > you can activate them in a bunch:
> > >
> > >   echo 'ft+p; mt+p; lt+p;' >control
> > >
> > > + * Parse `str' as a flags-spec, ie: [pfmlt_]*[-+=][pfmlt_]+
> >
> > This interface is simply _horrible_ and I do not see a point in this feature!!!
> >
> > I as a normal dynamic debug user am interested into:
> >
> >    + enabling/disabling messages from a given module/file/line/function
> >    + list of available modules/files/lines/functions
> >    + list of enabled modules/files/lines/functions
> >
> > I do not understand why I would ever want to do something like:
> >
> >    + enable messages that print module name and line number
> >    + disable message that does not print a module name
> 
> messages dont print them, the flags do, according to USER CHOICE.
> a developer who is deeply familiar with the code doesnt need to
> see most of it in the logs, average user might need them to comprehend things.

Any user, even average, has to deal also with non-debug messages that
do not include this extra information. Why pr_debug() message would
need it?

Message should be useful on its own. The location can be found by
grepping like for any other printk() messages.

Yes, the information might be handy. But all these configuration
choices also make the interface and code complicated. IMHO, it has
been over engineered. And this patch makes it even worse.


Anyway, you answered why the flags are there. But you did not explain
why anyone would need to use a filter based on them. Answer this,
please!!!


> > In fact, IMHO, all the 'flmt' flags were a wrong idea and nobody
> > really needed them. This information in not needed by other
> > printk() messages. Why pr_debug() would need them?
> > They just made the code and interface complicated.
> >
> 
> it looks like they landed fully formed in lib/dynamic_debug.c
> probably because that was a unification of several different print
> debug systems.

No, they were added by the commit 8ba6ebf583f12da32036fc0 ("Dynamic debug:
Add more flags").

There is no explanation why they were added. It probably just looked
like a good idea to the author and nobody complained at that time.

It has been included wihtout any comment, see
https://lore.kernel.org/lkml/201101231717.24175.bvanassche@acm.org/
https://lore.kernel.org/lkml/1300309888-5028-5-git-send-email-gregkh@suse.de/


> you are free to set them globally:
> echo +fmlt >control
> 
> or just the ones youre using
> echo up+fmlt >control

The question is not if I could do so. The question is how many users
do it or need to do so.

Features in this patchset affect the interface with userspace. It
means that they would need to be maintained "forewer". For this,
you need to prove that it is widely useful. Ideally, it should
be outcome of some discussion where people missed this.

I do not see any reasonable usecase for anything like:

   echo 'ft+p; mt+p; lt+p;' >control

Why people would do this, please?

Best Regards,
Petr

  reply	other threads:[~2020-06-18 16:01 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-17 16:25 [PATCH v3 00/21] dynamic_debug cleanups, query features, export Jim Cromie
2020-06-17 16:25 ` [PATCH v3 01/21] dyndbg-docs: eschew file /full/path query in docs Jim Cromie
2020-06-17 16:25 ` [PATCH v3 02/21] dyndbg-docs: initialization is done early, not arch Jim Cromie
2020-06-17 16:25 ` [PATCH v3 03/21] dyndbg: drop obsolete comment on ddebug_proc_open Jim Cromie
2020-06-17 16:25 ` [PATCH v3 04/21] dyndbg: refine debug verbosity; 1 is basic, 2 more chatty Jim Cromie
2020-06-17 16:25 ` [PATCH v3 05/21] dyndbg: rename __verbose section to __dyndbg Jim Cromie
2020-06-17 16:25 ` [PATCH v3 06/21] dyndbg: fix overcounting of ram used by dyndbg Jim Cromie
2020-06-17 16:25 ` [PATCH v3 07/21] dyndbg: fix a BUG_ON in ddebug_describe_flags Jim Cromie
2020-06-17 16:25 ` [PATCH v3 08/21] dyndbg: fix pr_err with empty string Jim Cromie
2020-06-17 16:25 ` [PATCH v3 09/21] dyndbg: prefer declarative init in caller, to memset in callee Jim Cromie
2020-06-17 16:25 ` [PATCH v3 10/21] dyndbg: make ddebug_tables list LIFO for add/remove_module Jim Cromie
2020-06-17 16:25 ` [PATCH v3 11/21] dyndbg: use gcc ?: to reduce word count Jim Cromie
2020-06-17 16:25 ` [PATCH v3 12/21] dyndbg: refactor parse_linerange out of ddebug_parse_query Jim Cromie
2020-06-17 16:25 ` [PATCH v3 13/21] dyndbg: accept 'file foo.c:func1' and 'file foo.c:10-100' Jim Cromie
2020-06-17 16:25 ` [PATCH v3 14/21] dyndbg: accept query terms like file=bar and module=foo Jim Cromie
2020-06-18 22:25   ` jim.cromie
2020-06-17 16:25 ` [PATCH v3 14/21] dyndbg: accept query terms like file=bar module=foo Jim Cromie
2020-06-17 16:25 ` [PATCH v3 14/21] dyndbg: accept query terms like module:foo and file=bar Jim Cromie
2020-06-17 16:25 ` [PATCH v3 15/21] dyndbg: export ddebug_exec_queries Jim Cromie
2020-06-17 16:25 ` [PATCH v3 16/21] dyndbg: combine flags & mask into a struct, simplify with it Jim Cromie
2020-06-17 16:25 ` [PATCH v3 17/21] dyndbg: refactor ddebug_read_flags out of ddebug_parse_flags Jim Cromie
2020-06-17 16:25 ` [PATCH v3 18/21] dyndbg: add filter channel to the internals Jim Cromie
2020-06-17 16:25 ` [PATCH v3 19/21] dyndbg: extend ddebug_parse_flags to accept optional leading filter-flags Jim Cromie
2020-06-18 12:44   ` Petr Mladek
2020-06-18 14:54     ` jim.cromie
2020-06-18 16:01       ` Petr Mladek [this message]
2020-06-17 16:25 ` [PATCH v3 20/21] dyndbg: add user-flag, negating-flags, and filtering on flags Jim Cromie
2020-06-17 22:13   ` Joe Perches
2020-06-17 22:57     ` jim.cromie
2020-06-18 16:19   ` Petr Mladek
2020-06-18 17:40     ` Petr Mladek
2020-06-18 18:17       ` Jason Baron
2020-06-18 19:11         ` jim.cromie
2020-06-18 19:40           ` Jason Baron
2020-06-18 21:31             ` jim.cromie
2020-06-18 22:34             ` Stanimir Varbanov
2020-06-18 22:48               ` jim.cromie
2020-06-19 16:07                 ` Jason Baron
2020-06-19  7:45           ` Petr Mladek
2020-06-19  8:10             ` Petr Mladek
2020-06-19  8:34               ` Greg KH
2020-06-18 18:15     ` jim.cromie
2020-06-17 16:25 ` [PATCH v3 21/21] dyndbg: allow negating flag-chars in modifier flags Jim Cromie
2020-06-17 20:05 ` [PATCH v3 00/21] dynamic_debug cleanups, query features, export Rasmus Villemoes

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=20200618160129.GC3617@alley \
    --to=pmladek@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=akpm@linuxfoundation.org \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jbaron@akamai.com \
    --cc=jim.cromie@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=orson.zhai@unisoc.com \
    --cc=will@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).