All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Jason Baron <jbaron@akamai.com>,
	jim.cromie@gmail.com,
	Daniel Thompson <daniel.thompson@linaro.org>
Cc: Stanimir Varbanov <stanimir.varbanov@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Documentation List <linux-doc@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-btrfs@vger.kernel.org, linux-acpi@vger.kernel.org,
	netdev@vger.kernel.org
Subject: Re: [PATCH v3 6/7] venus: Make debug infrastructure more flexible
Date: Thu, 11 Jun 2020 15:33:45 -0700	[thread overview]
Message-ID: <3518483f1836bdfbc193292dc1639509ac33fe7c.camel@perches.com> (raw)
In-Reply-To: <e65d2c81-6d0b-3c1e-582c-56d707c0d1f1@akamai.com>

On Thu, 2020-06-11 at 17:59 -0400, Jason Baron wrote:
> 
> On 6/11/20 5:19 PM, jim.cromie@gmail.com wrote:
> > trimmed..
> > 
> > > > > Currently I think there not enough "levels" to map something like
> > > > > drm.debug to the new dyn dbg feature. I don't think it is intrinsic
> > > > > but I couldn't find the bit of the code where the 5-bit level in struct
> > > > > _ddebug is converted from a mask to a bit number and vice-versa.
> > > > 
> > > > Here [1] is Joe's initial suggestion. But I decided that bitmask is a
> > > > good start for the discussion.
> > > > 
> > > > I guess we can add new member uint "level" in struct _ddebug so that we
> > > > can cover more "levels" (types, groups).
> > > 
> > > I don't think it is allocating only 5 bits that is the problem!

There were 6 unused bits in struct _ddebug;

The original idea was to avoid expanding the already somewhat
large struct _ddebug uses and the __verbose/__dyndbg section
that can have quite a lot of these structs.

I imagine adding another int or long wouldn't be too bad.

> > > The problem is that those 5 bits need not be encoded as a bitmask by
> > > dyndbg, that can simply be the category code for the message. They only
> > > need be converted into a mask when we compare them to the mask provided
> > > by the user.
> > > 

I also suggested adding a pointer to whatever is provided
by the developer so the address of something like
MODULE_PARM_DESC(variable, ...) can be also be used.

> > heres what I have in mind.  whats described here is working.
> > I'll send it out soon
> 
> Cool. thanks for working on this!

Truly, thank you both Jim and Stanimir.

Please remember that dynamic_debug is not required and
pr_debug should still work.

> >     API:
> > 
> >     - change pr_debug(...)  -->  pr_debug_typed(type_id=0, ...)
> >     - all existing uses have type_id=0
> >     - developer creates exclusive types of log messages with type_id>0
> >       1, 2, 3 are disjoint groups, for example: hi, mid, low

You could have a u8 for type if there are to be 3 classes

	bitmask
	level
	group by value

though I believe group by value might as well just be bitmask
and bool is_bitmask is enough (!is_bitmask would be level)

cheers, Joe


  reply	other threads:[~2020-06-11 22:34 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-09 10:45 [PATCH v3 0/7] Venus dynamic debug Stanimir Varbanov
2020-06-09 10:45 ` [PATCH v3 1/7] Documentation: dynamic-debug: Add description of level bitmask Stanimir Varbanov
2020-06-09 11:09   ` Matthew Wilcox
2020-06-09 11:16   ` Greg Kroah-Hartman
2020-06-09 16:58     ` Joe Perches
2020-06-09 17:42       ` Edward Cree
2020-06-09 17:56         ` Joe Perches
2020-06-09 18:08           ` Edward Cree
2020-06-10  6:31       ` Greg Kroah-Hartman
2020-06-10  6:35         ` Joe Perches
2020-06-10  7:09           ` Greg Kroah-Hartman
2020-06-10  7:24             ` Joe Perches
2020-06-10 10:29     ` Stanimir Varbanov
2020-06-10 12:26       ` Greg Kroah-Hartman
2020-06-09 10:45 ` [PATCH v3 2/7] dynamic_debug: Group debug messages by " Stanimir Varbanov
2020-06-09 12:27   ` Petr Mladek
2020-06-09 10:46 ` [PATCH v3 3/7] dev_printk: Add dev_dbg_level macro over dynamic one Stanimir Varbanov
2020-06-09 10:46 ` [PATCH v3 4/7] printk: Add pr_debug_level " Stanimir Varbanov
2020-06-09 11:12   ` Greg Kroah-Hartman
2020-06-09 10:46 ` [PATCH v3 5/7] venus: Add debugfs interface to set firmware log level Stanimir Varbanov
2020-06-09 11:12   ` Greg Kroah-Hartman
2020-06-11 11:51     ` Stanimir Varbanov
2020-06-09 10:46 ` [PATCH v3 6/7] venus: Make debug infrastructure more flexible Stanimir Varbanov
2020-06-09 11:14   ` Greg Kroah-Hartman
2020-06-10 13:29     ` Stanimir Varbanov
2020-06-10 13:37       ` Greg Kroah-Hartman
2020-06-10 19:49         ` Joe Perches
2020-06-10 20:23           ` Joe Perches
2020-06-11  6:26             ` Greg Kroah-Hartman
2020-06-11  6:42               ` Joe Perches
2020-06-11 10:52                 ` Daniel Thompson
2020-06-11 11:31                   ` Stanimir Varbanov
2020-06-11 12:18                     ` Daniel Thompson
2020-06-11 21:19                       ` jim.cromie
2020-06-11 21:59                         ` Jason Baron
2020-06-11 22:33                           ` Joe Perches [this message]
2020-06-12  0:08                         ` jim.cromie
2020-06-10 18:32   ` WIP generic module->debug_flags and dynamic_debug jim.cromie
2020-06-10 20:24     ` Joe Perches
2020-06-11 11:26     ` Rasmus Villemoes
2020-06-11 14:09       ` jim.cromie
2020-06-09 10:46 ` [PATCH v3 7/7] venus: Add a debugfs file for SSR trigger Stanimir Varbanov
2020-06-09 11:13 ` [PATCH v3 0/7] Venus dynamic debug Matthew Wilcox
2020-06-09 16:03   ` Randy Dunlap
2020-06-09 16:49     ` Joe Perches
2020-06-09 21:21       ` jim.cromie
2020-06-09 22:23         ` Joe Perches
2020-06-10  1:58           ` Joe Perches
2020-06-10  3:10           ` jim.cromie
2020-06-09 16:40 ` Joe Perches

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=3518483f1836bdfbc193292dc1639509ac33fe7c.camel@perches.com \
    --to=joe@perches.com \
    --cc=daniel.thompson@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jbaron@akamai.com \
    --cc=jim.cromie@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=stanimir.varbanov@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.