[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200609122755.GE23752@linux-b0ei>
Date: Tue, 9 Jun 2020 14:27:55 +0200
From: Petr Mladek <pmladek@...e.com>
To: Stanimir Varbanov <stanimir.varbanov@...aro.org>
Cc: linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
linux-btrfs@...r.kernel.org, linux-acpi@...r.kernel.org,
netdev@...r.kernel.org, Joe Perches <joe@...ches.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jason Baron <jbaron@...mai.com>, Chris Mason <clm@...com>,
Josef Bacik <josef@...icpanda.com>,
David Sterba <dsterba@...e.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <lenb@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v3 2/7] dynamic_debug: Group debug messages by level
bitmask
On Tue 2020-06-09 13:45:59, Stanimir Varbanov wrote:
> This will allow dynamic debug users and driver writers to group
> debug messages by level bitmask. The level bitmask should be a
> hex number.
>
> Done this functionality by extending dynamic debug metadata with
> new level member and propagate it over all the users. Also
> introduce new dynamic_pr_debug_level and dynamic_dev_dbg_level
> macros to be used by the drivers.
Could you please provide more details?
What is the use case?
What is the exact meaning of the level value?
How the levels will get defined?
Dynamic debug is used for messages with KERN_DEBUG log level.
Is this another dimension of the message leveling?
Given that the filter is defined by bits, it is rather grouping
by context or so.
> diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
> index 8f199f403ab5..5d28d388f6dd 100644
> --- a/lib/dynamic_debug.c
> +++ b/lib/dynamic_debug.c
> @@ -55,6 +55,7 @@ struct ddebug_query {
> const char *function;
> const char *format;
> unsigned int first_lineno, last_lineno;
> + unsigned int level;
> };
>
> struct ddebug_iter {
> @@ -187,6 +188,18 @@ static int ddebug_change(const struct ddebug_query *query,
>
> nfound++;
>
> +#ifdef CONFIG_JUMP_LABEL
> + if (query->level && query->level & dp->level) {
> + if (flags & _DPRINTK_FLAGS_PRINT)
> + static_branch_enable(&dp->key.dd_key_true);
> + else
> + static_branch_disable(&dp->key.dd_key_true);
> + } else if (query->level &&
> + flags & _DPRINTK_FLAGS_PRINT) {
> + static_branch_disable(&dp->key.dd_key_true);
> + continue;
> + }
> +#endif
This looks like a hack in the existing code:
+ It is suspicious that "continue" is only in one branch. It means
that static_branch_enable/disable() might get called 2nd time
by the code below. Or newflags are not stored when there is a change.
+ It changes the behavior and the below vpr_info("changed ...")
is not called.
Or do I miss anything?
> newflags = (dp->flags & mask) | flags;
> if (newflags == dp->flags)
> continue;
Best Regards,
Petr
Powered by blists - more mailing lists