Messages in this thread | | | Date | Thu, 18 Jun 2020 14:44:00 +0200 | From | Petr Mladek <> | Subject | Re: [PATCH v3 19/21] dyndbg: extend ddebug_parse_flags to accept optional leading filter-flags |
| |
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
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.
Please, stop all this non-sense!!!
Best Regards, Petr
| |