Thread (46 messages) 46 messages, 10 authors, 2020-06-12

Re: [PATCH v3 0/7] Venus dynamic debug

From: Joe Perches <joe@perches.com>
Date: 2020-06-09 22:23:17
Also in: linux-acpi, linux-arm-msm, linux-btrfs, linux-media, lkml, netdev

On Tue, 2020-06-09 at 15:21 -0600, jim.cromie@gmail.com wrote:
On Tue, Jun 9, 2020 at 10:49 AM Joe Perches [off-list ref] wrote:
quoted
(adding Jim Cromie and comments)
On Tue, 2020-06-09 at 09:03 -0700, Randy Dunlap wrote:
quoted
On 6/9/20 4:13 AM, Matthew Wilcox wrote:
quoted
On Tue, Jun 09, 2020 at 01:45:57PM +0300, Stanimir Varbanov wrote:
quoted
Here is the third version of dynamic debug improvements in Venus
driver.  As has been suggested on previous version by Joe [1] I've
made the relevant changes in dynamic debug core to handle leveling
as more generic way and not open-code/workaround it in the driver.

About changes:
 - added change in the dynamic_debug and in documentation
 - added respective pr_debug_level and dev_dbg_level
Honestly, this seems like you want to use tracepoints, not dynamic debug.
Tracepoints are a bit heavy and do not have any class
or grouping mechanism.

debug_class is likely a better name than debug_level
quoted
Also see this patch series:
https://lore.kernel.org/lkml/20200605162645.289174-1-jim.cromie@gmail.com/ (local)
[PATCH 00/16] dynamic_debug: cleanups, 2 features

It adds/expands dynamic debug flags quite a bit.
Yes, and thanks Randy and Jim and Stanimir

I haven't gone through Jim's proposal enough yet.
It's unfortunate these patches series conflict.

And for Jim, a link to Stanimir's patch series:
https://lore.kernel.org/lkml/20200609104604.1594-1-stanimir.varbanov@linaro.org/ (local)
As Joe noted, there is a lot of ad-hockery to possibly clean up,
but I dont grok how these levels should be distinguished from
KERN_(WARN|INFO|DEBUG) constants.
These are not KERN_<LEVEL> at all, all are emitted at KERN_DEBUG

These are just driver developer mechanisms to enable/disable
groups of formats via some test for < level or | bitmap
Those constants are used by coders, partly to convey how bad things are
As a user, Id be reluctant to disable an EMERG callsite.
Not possible.
are you trying to add a User Bit ? or maybe 7-9 of them ?
Or maybe a u32/ulong worth as most as I think the largest
current use is 32 bits of bitmask.
I have a patchset which adds a 'u' flag, for user.
Adapting that with an external bool for bitmask or class
would work fine.

	if (is_bitmask)
		enable/disable(value|flag)
	else
		enable/disable(value < flag)

So the equivalent of logical sets would work just fine.

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help